Enterprise Architecture Analysis - umu.se€¦ · enterprise architecture models and generates...

Master Thesis

Enterprise Architecture Analysis

Development of a Concrete Modeler Tool

Ann-Cathrin Dykström

Stockholm, Sweden 2009

XR-EE-ICS 2009:025

Abstract. The discipline of enterprise architecture advocates the use of models to support decision making on enterprise information system issues. It shall be possible to perform analyses of various properties in the enterprise architecture model, e.g. the availability, performance, information security and interoperability of the enterprise information system. The Department of Industrial Information and Control Systems has an idea of a software tool for analysis of enterprise architecture models. The tool guides in the creation of enterprise information systems scenarios in the form of enterprise architecture models and generates quantitative assessments of the scenarios. This master thesis paper presents the development of a concrete modeler part of this tool and a graph library to support development of visualization of models.

Keywords. Enterprise Architecture. Concrete Model. Java.

Table of Contents

1 INTRODUCTION 4 1.1 Organization of the Paper 4 1.2 Organization of the Work 4

2 PROBLEM 5 3 METHOD 5

3.1 eXtreme Programming 5 3.2 Software Development Environment 6

4 THEORY 7 4.1 Enterprise Architecture Analysis 7 4.2 Models 8

Abstract Model 8 Concrete Model 10

5 REQUIREMENTS SPECIFICATION 10 5.1 Concrete Modeler GUI 10

Entity 12 Attribute 12 Entity relation 13 Attribute relation 14 Relation association 14 CPM 15

5.2 Graph Visualization Library 15 6 DESIGN OF PROGRAM 15

6.1 Comparison of Graph Libraries 16 Prefuse 16 GINY 16 Netbeans Visual Library 16 Eclipse project GEF (Graphical Editing Framework) 16 JGraph 16

6.2 Graph Visualization Library 17 GraphScene 18 EntityWidget 18 AttributeWidget 19 EntityRelationWidget 19 AttributeRelationWidget 19 RelationWidget 19 ConnectNodeWidget 19 Relation 19 EntityRelation 19 AttributeRelation 20 RelationRelation 20

6.3 Concrete Modeler Facade 20

6.4 Concrete Modeler GUI 20 AttributeDialog 21 AttributeRelationDialog 22 CMGrapScene 22 ColumnGroup 22 ConcreteModeler 22 EntityDialog 22 EntityRelationDialog 23 Evidence 23 EvidenceDialog 23 GroupableTableHeader 24 GroupableTableHeaderUI 24 ModelerFrame 24 RowHeaderRenderer 25

7 DISCUSSION 26 8 CONCLUSIONS 26 9 REFERENCES 28

Dept. of Industrial Information and Control Systems KTH, Royal Institute of Technology, Stockholm, Sweden

1 INTRODUCTION

During the last decade, enterprise architecture has grown into an established approach for holistic management of information systems in an organization. Enterprise architecture is model-based, in the sense that diagrammatic descriptions of the system and their environment constitute the core of the approach. A number of enterprise architecture initiatives have been proposed, such as The Open Group Architecture Framework (TOGAF) [12], Enterprise Architecture Planning (EAP) [13] and the Zachman Framework [14]. Unfortunately there is no clear definition yet of what a “good” enterprise architecture model consist of. The reason is that the “goodness” of a model is not an inherent property, but dependent on the purpose of the model, i.e. what kind of analysis that will be done. For example, if one needs to employ an enterprise architecture model to evaluate the performance of an information system, the information required from the model differs from the case when the model is used to evaluate systems interoperability. Enterprise architecture analysis is the application of property assessment criteria on enterprise architecture models. For example, one investigated property might be the information security of a system and a criterion of assessment of this property might be “If the enterprise architecture model features an intrusion detection system, then this yields a higher level of information security than without such a system.” The Department of Industrial Information and Control Systems has an idea of a software tool for analysis of enterprise architecture models. The tool guides in the creation of enterprise information systems scenarios in the form of enterprise architecture models and generates quantitative assessments of the scenarios. The assessments can be of various quality attributes such as availability, usability, performance, security and interoperability. This master thesis paper presents the development of the user interface of a tool for analysis of concrete enterprise architectural models.

1.1 Organization of the Paper

Section 2 describes the problem that this master thesis shall solve. In section 3, the software development method and software development tools used are described, and section 4 briefly describes the theory behind enterprise architecture analysis and models. The requirements on the part of the tool developed in this master thesis are described in section 5. Section 6 describes the design of the concrete modeler part of the tool. Finally, the paper is concluded with a discussion and conclusion of the master thesis in sections 7 and 8.

1.2 Organization of the Work

The largest part of this master thesis work has been the design and implementation of a graph visualization library and a concrete modeler GUI. Parts of the work and dignity:

• Investigation and comparison of different available graph libraries, 10%

• Design and implementation of a graph visualization library and a concrete modeler GUI, 80%

• Writing of Master Thesis Report, 10%

- 4 -


2 PROBLEM

The first problem to be solved in this master thesis is the development of a first version of a Graphical User Interface (GUI), for the concrete modeler part of the Enterprise architecture Assessment Tool (EAT). The second problem to be solved is to select a graph visualization library which can support the development of EAT and to adapt it to EAT’s requirements. To develop the GUI, several GUI components need to be designed and implemented to produce a GUI in which the user can build and modify a concrete model. The user shall be able to add and remove entities, attributes and relations, to add evidence and make calculations. To select a graph visualization library a couple of libraries shall be investigated of which one shall be selected. Three parts needs to be developed:

• Concrete Modeler Façade.

• Concrete Modeler GUI

• Graph Visualization Library

3 METHOD

In this section the methods and tools used in this master thesis project is described. First is the software engineering methodology eXtreme Programming described and which parts of that which are used by the master thesis project and after that comes a short description of the software developing tools used.

3.1 eXtreme Programming

Extreme Programming (XP) is a software engineering methodology [1]. It is based on values of simplicity, communication, feedback and courage. If you follow XPs values it shall lead to more responsiveness to customer needs than traditional methods and creation of software with better quality. The main goal of XP is to reduce the cost of change of requirements during a project. In traditional development methods the requirements are determined in the beginning of the project, and are then fixed during the development. This means that the cost of a change will be high. XP tries to reduce this cost, and by applying XP a development project should be more flexible with respect to change. Extreme Programming has 12 practices, grouped into four areas [1]. Fine scale feedback

• Pair programming – All code is produced by two people programming one task on one workstation.

• Planning game – Meeting which is held once per iteration. Planning is divided into two parts, release planning and iteration planning. In release planning the customer and developers plan which requirements that shall be included in coming releases, and user story cards are written. Iteration planning plans the tasks for the developers and is done by the developers.

• Test-driven development – Unit tests are written before the code is written.

-5-


• Whole team – The customer/user shall be available at all times during the project to answer questions.

Continuous process

• Continuous integration – The developers shall always work on the latest version of the software, and should upload their latest changes often.

• Refactoring – Change the architecture of the code, make the code simpler and more generic when needed.

• Small releases – Make small releases often with parts of the total functionality. Shared understanding

• Coding standards – A set of rules that the development team shall adhere to.

• Collective code ownership – Everyone is responsible for all the code and are allowed to change any part of the code.

• Simple design – The developer shall choose a simple design as possible.

• System metaphor – A story that everyone can tell about how the system works. Programmer welfare

• Sustainable pace – The developers shall not work more than 40 hours a week. XP suites projects that have dynamic requirements, involve new technology, are small or/and need to adapt to rapidly changing business needs. This master thesis project have been inspired by eXtreme Programming, which was chosen by the researchers at the department. The practices chosen as most important are:

• Whole team – The customer in this project is the researchers at the Department of Industrial Information and Control Systems.

• Planning game – A modified version of XP planning is used containing release and iteration planning. The release planning in this project has been done by the customer who has written the user stories. The iteration planning should be done by the master thesis student and his/her supervisor.

• Test-driven development – Chosen to ensure that all code is properly tested before integration.

• Continuous integration – Is chosen to ensure that the code developed by different students is working together at the end.

• Refactoring – In the master thesis project not every student have that much development experience and therefore refactoring is an important practice.

• Coding standards – The standards used is Java coding conventions [4] and is ensured in code audit meetings. Coding standard is important to make the code easier to read and understand by other students.

• Simple design – Is chosen to make the code easier to understand by other master thesis students.

3.2 Software Development Environment

All programming in the master thesis project is done in Java [5]. Java is both a programming language and a platform. The platform has two components, the Java Virtual Machine and the Java Application Programming Interface (API). The API is a large collection of software-components. Functionality that is used in this project is for example Swing for Graphical User Interface (GUI) development and collections for data management.

-6-


The required Integrated Development Environment (IDE) to use in the master thesis project is Borland JBuilder [8] which has a built-in Swing GUI designer for GUI building. Netbeans IDE [8] is also used for GUI building and development. The source code is stored in CVS (Concurrent Versions System) [9]. It is an open source version control system that keeps track of the different versions of the source code. Castor [11] is an open source data binding framework for Java, which is used for reading and writing XML files. JSmile which is a Java interface to SMILE (Structural Modeling, Interference and Learning Engine) [12] is used for Bayesian Network calculations. SMILE is a C++ library implementing probabilistic and decision-theoretic models. Netbeans Visual Library [3] is used for visualizing of graph models. The use of Visual Library is described in more detail in Section 6.1.

Table 1 – Versions of tools and libraries used Tool/Library Version

Borland JBuilder 2006 Enterprise 12.0.203.0Java 1.5.0_03-b07Castor 0.9.7JSmile - CVS - Netbeans IDE 6.5Netbeans Visual Library Version distributed with

Netbeans 6.5

4 THEORY

In order to make rational decisions about information systems easier, some sort of support is needed. The problem to solve can be described in a set of potential scenarios of the information system. These different scenarios are then evaluated with the help of models, which are used to analyze different properties, e.g. performance, modifiability, security, and availability of the information system.

4.1 Enterprise Architecture Analysis

The purpose of enterprise architecture models and analysis is to make it easier to make rational decisions about information systems. The process of enterprise architecture analysis is illustrated in Figure 1. In assessment scoping, the problem is described in a set of potential future scenarios of the enterprise system and in terms of assessment criteria. The assessment criteria are the abstract model in the figure, with which the scenarios will be evaluated. The scenarios are the possible alternatives the decision maker has to choose between. The decision maker also needs to decide how to determine which one is the better scenario, the goal of the assessment. The second step is evidence collection, in which the scenarios are detailed by evidence collection, resulting in a set of concrete models. Much information about the involved systems and organizational context may be required to understand the future qualities of the scenarios. The decision maker needs to understand what information to gather and ensure that this information is collected and modeled.

-7-


In the last step, analysis, quantitative values of the models’ quality attributes are calculated. The models are then visualized as enterprise architecture diagrams. The decision maker can then trade the pros and cons of the different scenarios in order to determine which alternative to choose. Often many quality attributes are desirable as part of the calculation, for example high availability, high information security, high functional suitability, high interoperability, etc.

Figure 1 – The overall process of enterprise architecture analysis [2]

4.2 Models

There are two types of models in enterprise architecture analysis, abstract and concrete models. These models will be further described in the subsections below.

Abstract Model The causal relationships from decisions to quality attributes are complicated, and in order to understand these chains, an abstract model can be used. For example, the experience of a system administrator may affect the availability of the system he/she administrates. The systems availability can in turn affect the availability of the provided function, which is the quality attribute of interest.

-8-


Figure 2 - Example of an abstract model [2]

An abstract model contains four components: entities, attributes, entity relationships and attribute relationships see Figure 2. Of these, the first three can be recognized from class diagram notation of Unified Modeling Language (UML) [16]. Entities describes the items of interest of the model, such as “person”, “computer”, “process”, “function” or “data”. The entities can be connected to each other with entity relationships. In both ends role names are used (e.g. “uses” and “used by”). Multiplicity is indicated on the entity relationship. An entity contains of one or more attributes. The attributes are random variables which may assume values from a finite domain, for example {True, False}, {High, Medium, Low} or {1-10, 11-100, 101-1000}. They can represent concepts such as “Experience”, “Usability” or “Interoperability”. The last component is the attribute relationship which indicates a probabilistic dependence between two attributes. A change in the state of the source attribute is expected to lead to a change in the target attribute. These probabilities are used when performing assessments of quality attributes and are expressed in conditional probability tables (CPM). A CPM is a matrix, where the rows represent the states of an attribute and the columns represents the states of the source attributes in an attribute relationship. The CPM contains a probability for every state of the target attribute for every combination of the states of the source attributes. The example table below shows how a function’s availability attribute influences a system administrator’s responsiveness.

Table 2 – Example of a conditional probability table for a system administrators responsiveness Function.Availability High Medium Low System administrator.Responsiveness

High 1 0 0 Medium 0 1 0 Low 0 0 1

If an attribute relationship spans two entities, it is associated with a particular entity relationship, which is denoted by a line connecting the attribute relationship with the entity relationship, see Figure 2.

-9-


Concrete Model Detailed information, evidence, needs to be gathered about the scenarios so that an assessment can be performed. When the evidence has been collected they can be combined with the abstract model to form a concrete model. A concrete model is an instantiation of an abstract model. A concrete model defines a specific enterprise or information system, and for every scenario a new concrete model is generated.

Figure 3 – Example of a concrete model [2]

5 REQUIREMENTS SPECIFICATION

This section describes the requirements needed for development of a first version of the tool for Enterprise Architecture Analysis, described in section 4.

5.1 Concrete Modeler GUI

The Concrete Modeler GUI is the interface for the decision maker and investigator. It is used by the investigator to provide guidance in the evidence collection and to provide an interface for committing the evidence to the system. It is used by decision makers to determine goals of data collection and scoping, and to present the result of investigations. The requirements for the first version of the Concrete Modeler GUI are a mock up of the GUI and user stories describing how the GUI shall work.

-10-


Figure 4 - Mock up of main window with entities, attributes, entity relation and attribute relation General user stories:

• Concrete Model Visualization - The system shall provide visualization of the Concrete Model, i.e. visualizing entities, their attributes, entity relations, attribute relations and evidence according to the evidence file.

• Abstract Model Visualized in Concrete Modeler – The CM GUI should present an up-to-date graphical representation of the used Abstract Model. This graphical representation should be similar to that of the Abstract Modeler.

• Error Prevention – The system shall be designed so that it prevents errors that the user are capable of.

• Consistency and Standards – The system’s user interface design shall be consistent and operating principles shall conform to Java/Swing interface design standards.

• Error Recoverability – Error messages should conform to four principles. They should use clear language, have a high level of precision, be constructively helpful, and use polite, calm wording and appearance. The system shall provide fast error recovery functionality for instance by providing “undo” functions and by allowing users to edit incorrectly given input, rather than beginning from scratch.

• Match Between Systems and Real Word – When the system asks the user questions, or describes system status it should as far as possible be user-centric, and be based on user perspective.

• Recognition Rather than Recall – The system shall comply with the “principle of recognition rather than recall”.

-11-


• Unconnected Relations – When using the GUI to create abstract and concrete models, the system should not promote obvious syntactic errors.

• Visibility of System Status – When response time exceeds about 1.0 second, the system shall provide the user with feedback on what the system does and how it reacts to user input.

• Aesthetic and Minimalist Design – The user interface shall conform to the principle of aesthetic and minimalist design. The system shall conform to the “gestalt rules of human perception”.

• Invoke Calculation – In the Concrete Model GUI, the system shall allow the user to invoke the Bayesian calculations.

Requirements from Mock Up:

• It shall be possible to save a concrete model. The models data and the entities position coordinates shall be saved.

• It shall be possible to open a saved concrete model. The entities shall be shown at the saved coordinates.

Entity Entities are the items of interest in the model. Without entities there can be no model. It shall be possible to add and remove entities from the model. An entity has a name and a type which shall be possible to specify by the user when adding an entity.

Figure 5 - Mock up entity dialog window User stories:

• Add Entity – In the GUI of the Concrete Model, the system shall allow the user to add an entity.

• Move Entities – In the GUI of the Concrete Model the system shall allow the user to move around the entities in the model.

Attribute There must be at least one entity in the model before an attribute can be added. An attribute has a name, information on which entity it belongs to, evidence, Conditional Probability Matrix (CPM) and calculated values table. The user shall be able to set the attribute name, the entity in which it shall be created in, the evidence value, {High, Medium, Low} and CPM table. The calculated values shall be shown in a table.

-12-


Figure 6 - Mock up attribute dialog window with CPM User stories:

• Add Attribute – In the GUI of the Concrete Model, the system shall allow the user to add attributes to entities.

• Add Variable Evidence – In the GUI of the Concrete Model, the system shall allow the user to add attribute evidence.

• CM Attribute Hiding – In the GUI of the Concrete Model, the system shall allow the user to select if he wants to visualize the entities with attributes or not.

Entity relation There must be at least two entities in the model before an entity relation can be added. An entity relation has a name, a source entity and a target entity. It shall be possible to add and remove entity relations. When an entity relation is removed all attribute relations associated with the entity relation shall also be removed.

-13-


Figure 7 - Mock up entity relation dialog window User stories:

• Add Entity Relation – In the GUI of the Concrete Model, the system shall allow the user to add a relation between entities.

Attribute relation Attribute relations can be added between attributes in the same entity or between attributes in different entities. Attribute relations can only be added between attributes that belong to entities which has an entity relation. It shall be shown in the model which entity relation the attribute relation is associated with. An attribute relation has a name, a source attribute, a target attribute, a source entity and a target entity.

Figure 8 - Mock up attribute dialog window User stories:

• Add Attribute Relation – In the GUI of the Concrete Model, the system shall allow the user to add attribute relations.

Relation association An attribute relation that spans two entities, is always associated with a particular entity relation. This association shall be visualized in the GUI.

-14-


CPM A conditional probability is the probability that a state will occur given that another state has occurred. These relationships can be represented in a CPM. A CPM is a matrix, where the rows represent the states of an attribute and the columns represents the states of the source attributes in an attribute relationship. The CPM contains a probability for every state of the target attribute for every combination of the states of the source attributes. The example in Table 2 shows how a function’s availability attribute influences a system administrator’s responsiveness. A cell in the table can contain a value from 0 to 1. The rows represent the state in an attribute, for example {High, Medium, Low} or {True, False}. The columns represent the states from the source attribute in an attribute relation. When the attribute is added to an attribute relation as target attribute, the attribute’s CPM grows. See Figure 6 Mock up attribute dialog window with CPM. User stories:

• It shall be possible to show an attribute’s CPM in a table.

5.2 Graph Visualization Library

There shall be a library of standard graphical functions to facilitate the development of the Concrete Modeler GUI and the Abstract Modeler GUI. This library is preferably based on a standard library to get good performance and usability. It is part of this master thesis work to investigate what standard library to employ, and make the adaptations of the chosen library, that need to be done to suite the Enterprise architecture Assessment Tool (EAT).

6 DESIGN OF PROGRAM

Figure 9 – Concrete Model Manager [15]

-15-


The figure above, Figure 4, describes the overall design of the Concrete Modeler. The part that this master thesis covers is MT worker 2. The design of the three parts Concrete Modeler Façade, Concrete Modeler GUI and Graph Visualization Library will be described in the following sections.

6.1 Comparison of Graph Libraries

After investigation on internet forums and search of internet, five libraries were found and further investigated and compared. The five libraries are described below.

Prefuse Prefuse [19] is a set of software tools for creating interactive visualizations. It supports components for layout, panning, zooming, interaction and rendering of components. It is only available in a beta version and the documentation is not ready.

GINY GINY [20] is focused on networks and biological graphs. It hasn’t got the functionality to build model graphs and has no documentation.

Netbeans Visual Library Visual Library is designed for a general visualization with support for graph-oriented modeling. It becomes a part of the Netbeans platform when installed, but it is possible to use standalone by copying two .jar files and add to your Java classpath. The library comes with a lot of examples and there are several tutorials to be found on the Netbeans site [3]. It is based on the Swing Library and has a similar programming model, which makes it easy to learn if you have used Swing before. Several of Netbeans IDE tools have been developed using Visual Library and it is possible to reuse parts of the examples that come with the library. It supports zoom in/out, collapse/expand, Swing components on scene, satellite view, in place editing, animation, layouts etc.

Eclipse project GEF (Graphical Editing Framework) GEF [21] allows developers to create a rich graphical editor from an existing application model. It consists of two plug-in to the Eclipse platform, and to use it without the Eclipse platform is not supported. The main reason is a file in the platform that is used for string externalization (plugin.properties). GEF is open-source and it is therefore possible to modify it to be able to use it outside Eclipse. There are many articles on how to use and extend GEF. It supports printing, tool tips, selection, overview window, resize, undo/redo and has Model View Controller (MVC) architecture.

JGraph JGraph [22] is a feature-rich and standard-compliant open-source graph component and is recommended by the open-source community. It has a manual on how to use the API and how to add new types of graph vertices. It is a low level library and you have to do a lot by yourself and call several of the API methods to get a working example. JGraph is a big library with lots of functionality of which only a part will be needed for EAT. It supports various back ends such as XML, database, LDAP, edge editing, drag and drop, selection, sizing, clipboard, handles, undo/redo, labels and has MVC architecture.

-16-


Table 3 – Libraries compared Prefuse GINY Netbeans

Visual Library

Eclipse GEF JGraph

Documentation No No Yes Yes Yes Focused on model graphs

Yes No Yes Yes Yes

Released status Not released Released Yes Yes Yes Standalone Yes Yes Yes No Yes Prefuse and Graph INterface librarY (GINY) were not chosen because of lack of documentation, wrong focus and beta status. Eclipse Graphical Editing Framework’s (GEF) major drawback is its integration with Eclipse and its need to be modified to use in JBuilder. This modification has to be done at every new version of GEF. JGraph hasn’t got the same amount of articles as GEF, but it has an extensive manual and a lot of functionality. It is complicated and much code is needed to get a working application. Netbeans Visual Library was chosen because it is Swing library based and is easy to use standalone and in other IDEs such as JBuilder. That it is based on Swing, which is a standard Java library, makes it easy to understand if you have used Swing before. It has many examples and tutorials that can be of help when learning and using the library, and it is a high level API which makes it less complicated to find out which parts you need when developing.

6.2 Graph Visualization Library

The Enterprise architecture Assessment Tool’s (EAT) graph library API is an extension and adaptation of Netbeans Visual Library. Visual Library provides functionality for graph visualization. It is based on Java’s Swing Library and has a similar programming model. The adaptations made to Visual Library aim to provide methods and classes that make it easy to build EAT models, which adhere to EAT terminology, and to provide a common look and feel in different parts of EAT’s UI. A model is built as a tree of visual elements called Widgets. The root of the tree is a Scene which holds the visualization data. Each widget holds information about its location, boundary, layout, preferred/max/min sizes, border, foreground, background, font, cursor, tooltip etc.

-17-


Figure 10 – UML class diagram of the graph visualization library

GraphScene This is the class that manages the graph-oriented model. It inherits Visual Library’s GraphPinScene. GraphPinScene manages a model with nodes, pins and edges which in our GraphScene are renamed to entities, attributes and relations, which are the terms used in EAT. This class also manages the associations between entity relations and attribute relations. GraphPinScene use generics and therefore you can specify which classes that shall represent nodes, pins and edges. In the GraphScene class, the nodes are represented by String objects, the edges by objects of the Relation class, and the pins by String objects. There are three different types of edges, EntityRelations, AttributeRelations and RelationsRelations, and they all implement the interface (inherit) Relation. This inheritance is needed to be able to manage different edges (relations) in GraphScene, as GraphPinScene only manages one type of edges, which in our implementation are edges of type Relation. Maps with the entity’s/attribute’s name and id’s are kept to be able to map between the id in the model and its name in the graph. The maps are for example used when you know the id of an entity and need to get all its attributes names or you know the name of an attribute and need its id. The GraphScene class implements methods to add and remove entities, attributes and relations, to the scene. The methods use the node, pin and edge methods provided by GraphPinScene, set the visual look and behavior of the entities, attributes and relations, and create the bindings between objects and widgets.

EntityWidget This class is the visual representation of an entity. It extends Visual Library’s Widget class and controls how an entity is drawn on the scene. The EntityWidget’s size and layout is set and there are methods to attach attribute widgets, set name and type labels, and to minimize the entity widget. Which user actions the widget shall react on and what shall happen is specified, for example how shall the entity widget be drawn, when the user selects it and what shall happen.

-18-


AttributeWidget This class is the visual representation of an attribute. It extends Visual Library’s Widget class and controls how an attribute is drawn on an entity widget. The AttributeWidget’s layout and what user actions the widget shall react on are set. The class provides methods to get and set the attribute name label.

EntityRelationWidget This class is the visual representation of an entity relation. It extends Visual Library’s ConnectionWidget class and controls how an entity relation is drawn on the scene. The shape of the source and target points is set and the line thickness and color are set. The router which creates the path that the connection line takes between source and target is specified. A special node, a connect node widget is created and added to the EntityRelationWidget. The connect node widget is used as connection point for the associations between entity and attribute relations. Methods to set relation and multiplicity labels are provided and the user actions, hover, selected, highlighted, focused, which the relation widget shall react on are set.

AttributeRelationWidget This class is the visual representation of an attribute relation. It extends Visual Library’s ConnectionWidget class and controls how an attribute relation is drawn on the scene. The shape of the source and target points is set and the router which creates the path that a connection line takes between source and target is specified. The user actions hover, selected, highlighted and focused, on which the widget shall react, is set. A special node, a connect node widget is created and added to the AttributeRelationWidget. The connect node widget is used as connection point for the associations between entity and attribute relations.

RelationWidget This class is the visual representation of a relation relation, i.e. an association between relations. It extends Visual Library’s ConnectionWidget class and controls how a relation relation is drawn. The router which creates the path between the source and target is set and the user actions hover, selected, highlighted and focused are set.

ConnectNodeWidget This class is the visual representation of the point on an entity/attribute relation to which a relation relation can connect. The size and layout of this connection node is set.

Relation This is the interface that all relations must implement. It specifies the methods which are common for all types of relations, to get the relation’s id and create the relation’s widget class. Relations are used by the GraphScene class to build the models relationships.

EntityRelation This class implements a relation between two entities in a model graph. It implements the Relation interface and defines its methods. It also implements methods to set/get relationship names and multiplicity values.

-19-


AttributeRelation This class implements a relation between two attributes in a model graph. It implements the Relation interface and defines its methods.

RelationRelation This class implements an association between two relations in a model graph. It implements the Relation interface and defines its methods.

6.3 Concrete Modeler Facade

To minimize the communication and dependencies between the subsystems in EAT; the façade design pattern is used [17]. A façade object is used, which in the Concrete Modeler is called ConcreteModelFacade. The Concrete Modeler Façade provides a single interface, for the Concrete Modeler GUI, to access the functionality in the rest of the Concrete Modeler subsystem. The ConcreteModelFacade class is the only class that interacts with the rest of the subsystem. The ConcreteModelFacade class uses the class ConcreteModelManager, from the rest of the Concrete Modeler subsystem. The ConcreteModelManager is used to provide methods for the following functionality:

• Open, close and save a model.

• Add entities with position data to the model.

• Add attributes, entity relations and attribute relations to the model.

• Remove entities, entity relations and attribute relations from the model.

• Add evidence to an attribute.

• Get all entities and relations in a model.

• Get an entity’s attributes.

• Get an attribute’s “calculated values”, CPM and CPM states.

• Set an attribute’s CPM and parent attributes.

• Do a calculation on the model.

6.4 Concrete Modeler GUI

The Concrete Modeler GUI is the user interface for decision makers and investigators. It is used to visualize the concrete model graphically and for committing the evidence to the model. The Concrete Modeler GUI consists of 13 classes, most of them GUI components such as windows and dialogs. The ConcreteModelFacade class is used to communicate with the rest of the Concrete Modeler subsystem, and the Graph Visualization Library is used to visualize components of the model.

-20-


Figure 11 – UML class diagram of the Concrete Modeler GUI

AttributeDialog AttributeDialog is a user interface class that implements a dialog window in which the user can set the attribute name, the entity to which the attribute belongs, the evidence value, {High, Medium, Low} and CPM table. If there are any calculated values they will be shown in a table.

Figure 12 – Attribute dialog window

-21-


AttributeDialog extends Swing Library’s JDialog class for dialog window functionality, and implements ActionListener for listening on user input actions. The classes GroupableTableHeader and RowHeaderRenderer are used to implement the CPM and calculated values tables, and are further described below.

AttributeRelationDialog AttributeRelationDialog is a user interface class that implements a dialog window in which the user can set the name, source attribute, target attribute, source entity and target entity.

Figure 13 – Attribute relation dialog window AttributeRelationDialog extends Swing Library’s JDialog class for dialog window functionality and implements ActionListener for listening on user input actions.

CMGrapScene CMGraphScene implements the scene user interface component in which the model graph is shown. The user can move the entities around and zoom in on the model’s components. CMGraphScene extends the GraphScene class from Graph Visualization Library. It provides functionality to open a model and visualize it in the scene, to add/remove entities, attributes, entity relations and attribute relations to the model and to the model graph visualization in the scene. CMGraphScene uses the ConcreteModelFacade class to communicate with the rest of the Concrete Modeler subsystem.

ColumnGroup ColumnGroup implements grouping of a table’s columns to make it possible to show tables with multi-line column header. The original code in this class is implemented by Nobuo Tamemasa [18] and minor changes have been done to get it to work with EAT’s version of Java.

ConcreteModeler ConcreteModeler implements the Concrete Modeler GUI’s main class. It creates the application’s main window, ModelerFrame, and positions it in the middle of the screen.

EntityDialog EntityDialog is a user interface class that implements a dialog window in which the user can set the entity name and type.

-22-


Figure 14 – Entity dialog window EntityDialog extends Swing Library’s JDialog class for dialog window functionality and implements ActionListener for listening on user input actions.

EntityRelationDialog EntityRelationDialog is a user interface class that implements a dialog window in which the user can set an entity relation’s name, source entity and target entity. It extends Swing Library’s JDialog class for dialog window functionality and implements ActionListener for listening on user input actions.

Figure 15 – Entity relation window

Evidence Evidence is a container class that keeps evidence data such as name, statement and CPM.

EvidenceDialog EvidenceDialog is a user interface class that implements a dialog window in which the user can create evidence. It implements Swing Library’s ActionListener interface for listening on user input actions and extends JDialog class for dialog window functionality.

Figure 16 – Evidence dialog window

-23-


GroupableTableHeader GroupableTableHeader implements a table header which can have multiple lines. It extends Swing Library’s JTableHeader. The original code in GroupableTableHeader is implemented by Nobuo Tamemasa [18] and minor changes have been done to get it to work with EAT’s version of Java.

GroupableTableHeaderUI GroupableTableHeaderUI implements the painting of the GroupableTableHeader. It extends Swing Library’s BasicTableHeaderUI class. The original code in GroupableTableHeaderUI is implemented by Nobuo Tamemasa [18] and some minor changes have been done to make the table header look and work as expected.

ModelerFrame ModelerFrame implements the application’s main window. It holds the scene in which the model graph is visualized and gives the user the possibility to select a button to add entity, add attribute, add entity relation, add attribute relation, calculate and save or open a model.

Figure 17 – The modeler main window ModelerFrame extends Swing Library’s JFrame class for window functionality and implements ActionListener interface for listening on user input actions.

-24-


It uses CMGraphScene for visualization of the model graph and modification of the model. The dialog window classes, EntityDialog, AttributeDialog, EntityRelationDialog and AttributeRelationDialog, are used to give the user the possibility to modify the model graph.

RowHeaderRenderer RowHeaderRenderer implements a row header to add to a table. It extends Swing Library’s JLabel and implements the Swing Library interface ListCellRenderer.

-25-


7 DISCUSSION

The overall design of the first version of EAT and the concrete modeler part was given as input to the master thesis work by the customer, the researchers at the department. The façade design pattern had been chosen as interface object to the other parts of EAT. According to the given design the façade class would work as an interface for several classes outside the concrete modeler, but this isn’t the case in the implementation. Only one class is used, ConcreteModelManager. The façade class, ConcreteModelerFacade, has nevertheless worked as a given place to implement all methods that need to use methods in ConcreteModelManager and to provide an interface which is adapted to the Concrete Modeler GUI parts and thereby made the code more readable. It also reduces the dependency of the Concrete Modeler parts since future changes mostly will influence the implementation of the façade class. It is quite possible that in the future, the ConcreteModelerFacade will serve as a façade to several classes in the Concrete Modeler. The graph visualization library has been designed to support both the implementation of abstract model graphs and concrete model graphs. It provides classes to build models which has the same look and feel, when used by the different master thesis students building EAT’s parts. When the graph library is changed in the future it will change all parts of EAT using it and keep EAT’s parts looking alike. EAT terminology is used to make it easier to use for developers that has no experience of Visual Library. The first parts of the GUI were designed and implemented using the JBuilder GUI builder. It facilitated the GUI design as long as no Visual Library parts were added. When Visual Library components are added they aren’t visible in the GUI builder, and the developer is forced to open the Java code generated by the builder. This code is structured to be easily generated and not to be easy to read. Later parts of the GUI have been designed in the Netbeans GUI builder, which generates more readable and modifiable code, and then moved to JBuilder. The Graph Visualization Library performance is by and large dependent on Visual Library’s performance, since it is built on Visual Library. The Visual Library has been tested, in one of the Netbeans examples [3], with over 1000 nodes and edges and performed well. XP, eXtreme programming was selected by the customer, the researchers at the department, as the development methodology for the master thesis project. It has been difficult to adhere to all the selected XP practices, because the master thesis students work much independently. To make use of XP’s advantages, more collaboration between the different students is needed, and the customer needs to be more involved in the iteration planning and selection of which user stories to implement.

8 CONCLUSIONS

In this master thesis, a first version of a concrete modeler GUI has been developed. All the parts of the mock up, provided as input to this master thesis, have been implemented. All the user story requirements have been adhered to, except the following stories:

• Abstract Model Visualized in Concrete Model – There is no connection to an abstract modeler because no such GUI existed at the time of this master thesis.

• CM Attribute Hiding – The code for this has been developed in the Graph Visualization Library but isn’t used due to conflict with the implementation of the relation associations (RelationRelation). The requirement for relation associations was added after the CM attribute hiding was developed, and due to lack of time was not integrated with the attribute hiding.

To make the attribute hiding work in the future, some refactoring and additions, needs to be done to the graph visualization library. The hiding of the relation associations needs taking care of.

-26-


This version of a concrete modeler contains functionality that belongs to an abstract modeler, such as adding different types of entities and adding attributes to entities. It is kind of a hybrid between an abstract modeler and a concrete modeler. This will have to be changed, when an abstract modeler has been developed, in a future version of EAT.

-27-


-28-

9 REFERENCES

[1] Beck, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000.

[2] Johnson P., Johansson E., Sommestad T., Ullberg J. A Tool for Enterprise Architecture Analysis Department of Industrial Information and Control Systems Royal Institute of Technology

[3] Netbeans Visual Library in NetbeansPlatform 6.0 http://graph.netbeans.org, accessed Mars 2009

[4] Code Conventions for the Java Programming Language http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html, accessed April 2009

[5] The Java Tutorials http://java.sun.com/docs/books/tutorial, accessed April 2009

[6] The Java Technology Phenomenon http://java.sun.com/docs/books/tutorial/getStarted/intro/index.html, accessed April 2009

[7] Borland JBuilder http://www.borland.com, accessed April 2009

[8] Netbeans http://www.netbeans.org/index.html, accessed April 2009

[9] CVS - Concurrent Versions System http://www.nongnu.org/cvs/, accessed October 2009

[10] The Castor Project http://www.castor.org, accessed April 2009

[11] GeNIe & SMILE http://genie.sis.pitt.edu/online_docs.html, accessed April 2009

[12] The Open Group The Open Group Architecture Framework, Version 8, 2007

[13] Spewak, S.H, Hill S.C Enterprise Architecture Planning. Developing a Blueprint for Data, Applications and Technology, John Wiley and Sons, 1992

[14] Zachman, J. A framework for information system architecture, IBM System Journal, 26(3), 1987

[15] The Enterprise Architecture Assessment Tool http://eawiki.ics.kth.se, accessed April 2009

[16] Unified Modeling Language http://www.uml.org, accessed April 2009

[17] Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995

[18] JTable Examples 1 http://www.crionics.com/products/opensource/faq/swing_ex/JTableExamples1.html, accessed April 2009

[19] Prefuse interactive information visualization toolkit http://prefuse.org, accessed 2007

[20] Graph Interface library a.k.a. GINY http://csbi.sourceforge.net/white_paper.html, accessed 2007

[21] Graphical Editing Framework http://wiki.eclipse.org/Graphical_Editing_Framework, accessed October 2009

[22] JGraph Visualization and Layout http://www.jgraph.com, accessed October 2009

http://graph.netbeans.org/

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

http://java.sun.com/docs/books/tutorial

http://www.borland.com/

http://www.netbeans.org/index.html

http://www.nongnu.org/cvs/

http://www.castor.org/

http://genie.sis.pitt.edu/online_docs.html

http://eawiki.ics.kth.se/

http://www.uml.org/

http://www.crionics.com/products/opensource/faq/swing_ex/JTableExamples1.html

http://prefuse.org/

http://csbi.sourceforge.net/white_paper.html

http://wiki.eclipse.org/Graphical_Editing_Framework

http://www.jgraph.com/

Enterprise Architecture Analysis - umu.se€¦ · enterprise architecture models and generates...

Documents

Transcript of Enterprise Architecture Analysis - umu.se€¦ · enterprise architecture models and generates...