NetBeans Architecture Answers for UML Modeling Core module

General Information

Question (arch-what): What is this project good for?
Answer:

This project is a core module for the modeling tool.

Question (arch-overall): Describe the overall architecture.
Answer: The UML project is really a modeling project. One of the things (and currently the only thing) that we can model is UML. The tool is broken up into three areas Core, Language Framework, and UI.



Modeling Core

The Core contains the meta data layer, workspace management, event framework, preference framework, type management, generative framework, and a add-in framework. Below is a brief description to each of the components for the tool. When reading the descriptions keep in mind that the UML tool was originally designed as an application that can be embedded into other application shells. So, some of the components listed are duplicates of NetBeans components.

• Meta Data Layer

The meta data layer is based on the UML specification. Our data for the most part follows the UML specification. The interesting thing about UML 2.0 is that the architects of UML 2.0 also designed MOF 2.0. So at this point UML 2.0 is a super set of MOF 2.0. When ever a meta data element has a value changed the event framework is used to notify listeners of the change. The only business rules that the meta data layer applies are to force the correct structure data structure. The applications business rules are applied by other components in response to events sent out when a model element is about to be modified. We call these events pre events. For example when the name of a class model element is changed a name change event is sent and round trip listens for name change events and verify that the name is a valid identifier for the languages associated with the model element.

• Workspace Management

Describe was design be able to have multiple UML projects open at the same time. The job of the workspace management component was to manage the projects that are open. NetBeans 4.x has its own workspace management facilities. In Coke we will probably no longer have a dependency on this component.

• Event Framework

The event framework is a component that does not have any dependencies to the rest of the application. However most of the rest of the tool has dependencies on the EventFramework We did not use the Java Bean event mechanisms, instead we used more of an event bus mechanism. The event mechanism is broken into event dispatchers, and event listeners. The event dispatchers are used to register listeners for events and to send events to all registered listeners. There is a number of different types of dispatchers in the tool (for example ElementChangeEventDispatcher, AddinEventDispatcher, ElementLifeTimeEventDispatcher etc) and any component can create a new event dispatcher. The component that would like to register for an event retrieves the dispatcher and registers for the event. The big difference between our event mechanism and the JavaBeans event mechanism is that you do not have to wait for a component to be created before registering for the events. For example with the JavaBean event mechanism you have to have an instance of the bean that you wish to register with. So, if you want to receive notification from all class elements in the system you have to first register for an event to notify you when a class comes into memory, register for the event with the class and then you are able to receive events. With the event bus concept the component retrieves the event dispatchers when the component is created, registers for the event and waits. Whenever something any class changes the registered listener will be notified.

• Preference Framework

Again Describe was designed to be an application that could be embedded into many shells. As such we have our own preference framework. We may want to start using the NetBeans preference mechanism in the future.

• Type Management

Type management is used to quickly find type in the system. Type management is also the component that makes version control possible. When model element is versioned we remove the model element information from the project and replace it with a stub. The removed information is then gets stored into its own file (.ext) that can be version controlled. When a versioned model element is referenced the Type Management component make sure that the information in the version controlled file is read in to memory and replaces the stub with the information in the version control file. In this way we are able to lazy load information.

• Generative Framework

The generative framework is used to format data. Basically we are able to use scripts to format information. The scripts are used to format the information in the diagram, project tree, and property editor. In the C++ version of Describe the generative framework was also used to generate code.

• Add-In Framework

Again since Describe was designed to embed into different shell we also developed our own add in framework.





Langauge Facility

The language facility supplies the language processing of the modeling tool. The modeling tool was design to maximize the reuse of the components across languages. In the modeling domain when we use the term language we are talking about anything that can be generated. It could be used to generate a source file, XML or a StarOffice document the framework does not care. The language facility contains the parsers, reverse engineering, method body reverse engineering, round trip framework, and code generation.</blockquote>[</html>]
• Language Parsers

The parsers that we use in the UML tool generate events. The events are structured using UML syntax (actually they are XMI fragments). Because we use UML as our event syntax all parser listeners are able to be language agnostic because the structure of the event will look the same if the language is Java, C++, C#, VB, JSP, etc.

• Reverse Engineering

Takes the parser information and integrates the information into a modeling project. The modeling project can be a new project or an existing project. Note that there is only one Reverse Engineering component that can handle all of the languages. Basically it is language agnostic.

• Method Body Reverse Engineering

Takes the parser information and integrates the information into the modeling project by creating an interaction (Sequence Diagram, or Collaboration Diagram) that represents the parser information. Note that there is only one Method Body Reverse Engineering component that supports all of the languages.

• Round Trip

Round trip has two purposes in life: one enforce business rules that apply to languages, two notify the code generation that something changed that affect the associated source file artifacts. Round trip registers for many of the events that can be issued from the meta data, validates the data and applies business rules. After the data changes have been applied round trip sends an event via the RoundTripEventDispatcher to notify listeners that the source file artifact may need to be updated. Round trip is not actually responsible for generating any code. Code generation is the responsibility of the round trip listeners. To apply the business rules for a language round trip uses a component called a request process to apply the rules. Each supported language supplies a request processor. So the request processor is not language agnostic, however round trip (which only manages the request processors) is language agnostic. A configuration file is used to determine the request processor to use for a specific language. Round trip was designed to allow multiple languages to be associated with one model element. So a model element can be associated with Java, and WSDL and the code can be generated for each language. When the model element is changed the code will be generated for both languages without any interaction by the user.

• Code Generation

Code generation (you guessed it) is used to generate code. In Java Studio Enterprise the Java code generator uses the NetBeans API to generate code. However, that does not have to be the case. As mentioned earlier the C++ version of Describe the code generation module to use the generative framework to generate code. The code generation component is registered as a round trip listener for a specific language. Therefore the Java code generation component only recieves events when a Java source artifact is associated with a model element that has been modified. When something occurs in the model that affects a source artifact the code generation component is notified via round trip events. The code generation module then updates the source file.





Modeling User Interface

The interfaces provides many visual components to allow the user to interact with a model. Below is a description of the user interfaces components.
• Drawing Area

The drawing area component is used to render the diagrams The drawing area control wrapes the Tom Sawyer components. The drawing area control is a generic control that can be used to when developing any modeling diagram. Even though the UML product has multiple diagram types there is only one drawing area control for all the diagrams.

INSERT A DIAGRAM HERE



• Property Elements/Property Definitions
The modeling tool has a concept of property elements and property definitions. Property definitions a basically a meta language that can be used to describe the structure of properties. The property definitions specify the details of a property. The property definition fields are listed below.

Property elements is an instance of the property defintions. The property elements contain the properties data and a pointer to the property definitions that specifies the property elements rules. The property elements and property definitions are defined as interfaces so there are unlimited posibilities of how to load up the property elements data and how to build the property defintion tree.

The modeling tool supplies one implementation of the property elements and property defintions that can be built a runtime based on an XML files. The propety definition file specifies the structure of the property definitions and the property element file specifies all the informtion that is needed to set and retrieve the property data. Reflection is used to set and retrieve the property data.
• Propertery Editor

The property editor is a generic property editor that uses the property elements/property definitions mentioned above to build property data. Since the property definitions can contain children the property editor was design to display properties in a tree structure.

• Project Tree
• Preferences Editor
* Edit Control


• Documentation Pane
Question (arch-usecases): Describe the main use cases of the new API. Who will use it under what circumstances? What kind of code would typically need to be written to use the module?
Answer:

Fill in at a later time.

Question (arch-time): What are the time estimates of the work?
Answer:

The modeling module will be released in the BUZZ time frame.

Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented?
Answer:

We have a few hundred JUnit test that we currently run during our release engineering process. As we move forward we will be building more JUNIT test that will be executed. Our quality assurance team is in the process of building suite of automated test modules to test the UI components. We have also instructed the quality assurance team that once the UI test are completed that when a new is written we also want a automated test that engineering can run to replicate the problem. By having our quality assurance team assist in the automated test genreation we will be able to have a high rate of successfully replicating issues as well as have a higher number of automated test.

Project and platform dependencies

Question (dep-nb): What other NetBeans projects and modules does this one depend on?
Answer: It uses various kinds of API's:
• OpenIDE The support class various NetBeans classes.
• Loaders Provides the DataObject implementation
• projectapi Provides the NetBeans project API.
• ant-project Provides the Ant project suppport.
• projectapi Provides the project chooser, and customizer support.
• projectuiapi E.g. Debug uses InputOutput.
Question (dep-non-nb): What other projects outside NetBeans does this one depend on?
Answer:

Antlr 2.7.2
Tom Sawyer version 6.0

Question (dep-platform): On which platforms does your module run? Does it run in the same way on each?
Answer:

100% pure Java. It should run anywhere.

Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)?
Answer:

JRE 1.5

Question (dep-jrejdk): Do you require the JDK or is the JRE enough?
Answer:

The JRE is enough.

Deployment

Question (deploy-jar): Do you deploy just module JAR file(s) or other files as well?
Answer: The module deploys the following jar files into lib/ folder:
• lib/dom4j/jaxen.jar
• lib/dom4j/msv.jar:
• lib/dom4j/PullParser2.jar:
• lib/dom4j/relaxngDatatype.jar:
• lib/dom4j/saxpath.jar:
• lib/dom4j/Tidy.jar:
• lib/dom4j/xsdlib.jar:
• lib/junit/junit.jar
Question (deploy-nbm): Can you deploy an NBM via the Update Center?
Answer:

XXX no answer for deploy-nbm

Question (deploy-shared): Do you need to be installed in the shared location only, or in the user directory only, or can your module be installed anywhere?
Answer:

Module can be installed any where.

Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public?
Answer:

Yes. Public packages of J2EE Server API module are specified in module manifest file : com.embarcadero.uml.**

Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one?
Answer:
• UML Projects - com.sun.tools.ide.uml.project
• Associate Model Elements - com.sun.tools.ide.modeling.associatewith
• Rose Import - com.sun.tools.ide.modeling.roseimport
• Web Report - com.sun.tools.ide.modeling.webreport
• Diagram Creator - com.sun.tools.ide.modeling.diagramcreator
• Documentation Pane - com.sun.tools.ide.modeling.documentation
• Modeling Drawing Area Control - com.sun.tools.ide.modeling.drawingarea
• Modeling Source Control - com.sun.tools.ide.modeling.sourcecontrol
• Requiremetns Framework - com.sun.tools.ide.modeling.requirements
• Reverse Engineering GUI - com.sun.tools.ide.modeling.regui

Compatibility with environment

Question (compat-i18n): Is your module correctly internationalized?
Answer:

Yes

Question (compat-standards): Does the module implement or define any standards? Is the implementation exact or does it deviate somehow?
Answer:

The module implements the MOF 2.0/UML 2.0 as of the Jan 2003 version of the OMG specification.

Question (compat-version): Can your module coexist with earlier and future versions of itself? Can you correctly read all old settings? Will future versions be able to read your current settings? Can you read or politely ignore settings stored by a future version?
Answer:

This version will be compatable with the previous version of the modeling product. In the future we will be moving our configration file into the NetBeans layer mechanism.

Access to resources

Question (resources-file): Does your module use java.io.File directly?
Answer:

We use Files when ever reading in configuration files. We also use the File class when reading in metadata and diagram files.

Question (resources-layer): Does your module provide own layer? Does it create any files or folders in it? What it is trying to communicate by that and with which components?
Answer:

Yes. We use the configuration files and folders to allow modules writers add context menus, to extend the Modeling components.

Question (resources-read): Does your module read any resources from layers? For what purpose?
Answer:

Yes. We use the configuration files and folders to allow modules writers add context menus, to extend the Modeling components.

Question (resources-mask): Does your module mask/hide/override any resources provided by other modules in their layers?
Answer:

No

Lookup of components

Question (lookup-lookup): Does your module use org.openide.util.Lookup or any similar technology to find any components to communicate with? Which ones?
Answer:

We have added IElement instances to lookup of our nodes. Our UML project type also creates a lookup and adds the standard project classes to the lookup. We also add a UMLHelper to the lookup to allow modules writers to interact with tha model.

Question (lookup-register): Do you register anything into lookup for other code to find?
Answer:

We have added IElement instances to lookup of our nodes. Our UML project type also creates a lookup and adds the standard project classes to the lookup. We also add a UMLHelper to the lookup to allow modules writers to interact with tha model.

Question (lookup-remove): Do you remove entries of other modules from lookup?
Answer:

No

Execution Environment

Question (exec-property): Is execution of your code influenced by any environment or Java system (System.getProperty) property?
Answer:
• embarcadero.home-dir - Sets the directory that will contain the .uml configuration files.
Question (exec-component): Is execution of your code influenced by any (string) property of any of your components?
Answer:

No

Question (exec-ant-tasks): Do you define or register any ant tasks that other can use?
Answer:

We use the Antlr ant task that ships as an optional task in the Ant distribution.

Question (exec-classloader): Does your code create its own class loader(s)?
Answer:

No

Question (exec-reflection): Does your code use Java Reflection to execute other code?
Answer:

The UML code is very dynamic. We use configuration files to determine how to populate our tree, property editor, edit control, and preferences. The configuration file specifies that methods that should be used to retrieve, modify, and remove items from a given object.

Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection?
Answer:

No

Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code?
Answer:

No

Question (exec-introspection): Does your module use any kind of runtime type information (instanceof, work with java.lang.Class, etc.)?
Answer:

No

Question (exec-threading): What threading models, if any, does your module adhere to?
Answer:

We call the VCS API that is not able to run on the UI thread with out locking up the application. To solve this problem our VCS module has started a thread and executes all VCS API commands on the thread.

Question (security-policy): Does your functionality require modifications to the standard policy file?
Answer:

No

Question (security-grant): Does your code grant additional rights to some other code?
Answer:

No

Format of files and protocols

Question (format-types): Which protocols and file formats (if any) does your module read or write on disk, or transmit or receive over the network? Do you generate an ant build script? Can it be edited and modified?
Answer:

We store our meta model information in files that have an etd extension. We store our diagrams in that end with the extensions etlp, and etld. Also when we version control model elements we store the metamodel information in a files with the extension etx.

Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop?
Answer:

DnDConstants.ACTION_COPY, DnDConstants.ACTION_MOVE

Question (format-clipboard): Which data flavors (if any) does your code read from or insert to the clipboard (by access to clipboard on means calling methods on java.awt.datatransfer.Transferable?
Answer:

To perform DnD between the project tree and the diagrams we use a transferable that keeps track of the model elements that are selected. We provide our own data flavor that can be used to retrieve the model elements that are the target of the operation.

The transferable also implements the string flavor that can be used to pass the model element information. The string format is a XML string.

We use the same transferable when performing the copy and paste operations.

Performance and Scalability

Question (perf-startup): Does your module run any code on startup?
Answer:

UML initializes the UML product durning the module startup.

Question (perf-exit): Does your module run any code on exit?
Answer:

No

Question (perf-scale): Which external criteria influence the performance of your program (size of file in editor, number of files in menu, in source directory, etc.) and how well your code scales?
Answer:

No

Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle?
Answer:

No

Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc.
Answer:

The size of memory that our module consumes depends on the size of the model. The bigger the model the bigger the XML repository.

Question (perf-wakeup): Does any piece of your code wake up periodically and do something even when the system is otherwise idle (no user interaction)?
Answer:

No

Question (perf-progress): Does your module execute any long-running tasks?
Answer:

Create Diagram form selected, and Sequence Diagram Reverse Engineering can take a while to complete.

Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas?
Answer:

No

Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic?
Answer:

No

Question (perf-spi): How the performance of the plugged in code will be enforced?
Answer:

Currently we do not have any enforcement.