Element Features |
  
|
Element Features |
|
In a little-known corner of EA is the idea of the Element Feature. It may be small, and carefully hidden, but it has in it a very powerful idea, which eaDocX can help you to use.
Element Features solves the problem of linking Elements - Use Cases, Classes, Requirements, Component etc, to individual Attributes or Methods. This might not sound like something you have ever wanted to do, be read on....
Suppose you are describing a User Interface, using EA's UI modelling capabilities. What EA allows you to do is to link ideas in the UI world with ideas from elsewhere in our model. For a UI, it might be really useful to say which UI widgets correspond to which attributes and methods in your conceptual model:
You might also have created a 'Customer' class in your conceptual model:
Before we had EA Element Features, we could link the 'Customer Details' screen with the 'Customer' class, to say that the one displayed the other:
but Element Features allows us to go to a deeper level of detail, and link individual widgets in the UI to individual Attributes and Methods in the Customer class:
So you can now see exactly how the Customer class corresponds to the User Interface dialogue. This makes it much easier to spot where they may be attributes in the class which aren't getting displayed, or UI widgets that display data which hasn't come from the conceptual model.
eaDocX allows you to print Element Feature details just like any other attribute. Any Element type, and Attributes and Methods, can print an attribute called 'element Features'. So, in the example above, if we were to print both the details of the UI widgets and the Customer class, we would get a document like this:
.1Customer details screen
Widget |
Name |
Conceptual Model Reference |
|---|---|---|
win32StaticText |
Name: |
|
win32StaticText |
Credit Card number: |
|
win32Button |
Validate |
Customer::checkAddress |
win32Button |
Save |
Customer::saveNewCustomer |
win32Button |
Cancel |
|
win32Edit |
(cc number) |
Customer::checkCreditCardNumber |
win32Edit |
(address) |
Customer::address |
win32StaticText |
Address: |
|
win32Edit |
(name) |
Customer::name |
.1Conceptual Model
.1.1Customer
.1.1.1Attributes
Type |
Widget |
User Interface Ref |
|---|---|---|
String |
name |
(name) |
string |
address |
(address) |
string |
Credit Card Number |
|
.1.1.2Methods
Name |
Return Type |
UI Reference |
|---|---|---|
checkAddress |
boolean |
Validate |
checkCreditCardNumber |
boolean |
(cc number) |
saveNewCustomer |
boolean |
Save |
This is providing a high level of traceability between the two models.
Another example of where Element Features can be used for this traceability is between different types of class model. For example, between a Conceptual model and its database model:
The Customer class would now print out like:
Type |
Database model reference |
Database Model reference |
|---|---|---|
String |
name |
T_Customer |
string |
address |
T_Address |
string |
Credit Card Number |
T_Credit_Card_Details::number |