Messages

1

Suggestions and Requests / Partial Classes

« on: March 02, 2007, 10:33:25 am »

Don't know if we're doing it right, but reverse engineering partial classes (the class definition is spread across a couple files) doesn't quite work.  It creates a more than one object for the class.

2

Suggestions and Requests / Re: Sequence Diagrams and Parameters

« on: February 28, 2007, 02:58:55 pm »

Have you tried the putting cacheList := false in the constraint box on the properties page?   or attaching a constraint to the method?

3

Suggestions and Requests / Re: UML driven testing

« on: February 28, 2007, 11:22:07 am »

...

In the meantime, this would likely fit well with formatted Notes in elements (of all kinds, not just requirements). Lately we're mostly talking about RTF, but perhaps XML is the way to go.

Well, I've played a bit more...
There are two levels of formatted text that I would use.
The first helps in parsing the elements of a well-formed requirement. (Capability, Constraints, Conditions). For conditions, I am viewing them as states and I express them as StateMachineName.State (it should have the option for a natural language description for documentation purposes.  This can be used to stub out two test methods: Verify_StateMachine.State and Set_StateMachine.State.

For constraints, I am adopting a set description. I haven't flushed out all the details. But I see constraints as limits on parameterization, hence the set description paradigm.

Constraints would set the boundaries for good values, the tester can select values outside the boundaries to force failures.

So where they are kept in the model must permit "mining" the information for test generation.

Could you just include the XML in the Requirement Details field, or provide a reference to external XML via the Files tab? Like you I'd like to keep this inside the EA model (via the schema) but perhaps an external file would be enough for now.

For now I am just exporting the sequence diagrams and manually adding conditions and constraints.  I am looking for a long term, more user friendly approach so I can get our processes more widely adopted.

I have been playing with tagged values. Perhaps these can meet the need.

4

Suggestions and Requests / Re: UML driven testing

« on: February 05, 2007, 09:50:02 am »

In order to give proper credit I have gone back and found where I got the classification system.

Michael Jackson published some works through IEEE years ago and now has a book on it.

http://www.amazon.com/exec/obidos/ASIN/020159627X/qid=967405083/103-5241225-1144601

I will purchase the book just to refresh my memory.

5

Suggestions and Requests / Re: UML driven testing

« on: February 01, 2007, 08:11:08 am »

<SNIP>

Would you be able to provide a more normative definition of each of these categorizations?  Also, do you apply them as stereotypes?

TIA,
Paolo

Currently I am just starting with EA so the only thing I currently do with it is draw UML diagrams and export them. But I am hoping to make it central to our whole Requirements Engineering and Testing processes.

I will take the discussion of our processes to another discussion so as not to clutter the new features requests.
See General Board:Requirements Engineering:Capability Types

6

Suggestions and Requests / Re: UML driven testing

« on: January 31, 2007, 04:31:36 pm »

Hmm,

Ouch, That is really painful for data entry. If I am doing it right.  I am having to open a dialog for every element of the schema?  

I'll try some more tomorrow.  Thanks.

7

Suggestions and Requests / Re: UML driven testing

« on: January 31, 2007, 10:48:03 am »

Sorry,

The direct answer is that I would much prefer to have it in the model.

8

Suggestions and Requests / Re: UML driven testing

« on: January 31, 2007, 10:41:13 am »

I would like to do a lot of data mining for "completeness" and "comprehensiveness" type reviews.  

Hence I have another whole level of structure I would like to innclude as well.

For instance, I classify each requirement into one of these categories:

Commanded Behavior
Required Behavior
Information Display
Transformation
Work Piece
SYnchronization

Each type has a schema that requires more information.

For instance, a Synchronization requirement has a master, one or more slaves, a data set, and quality of service information.

A query based on a slave actor name would give me a full set of requirements for that actor.

If I add the Structured language to the Notes, then I must export everything before I can do queries.

It would be must nicer if I could attach an xsd to the note field so that the type definition would determine the structure of the field.

9

Suggestions and Requests / UML driven testing

« on: January 31, 2007, 10:21:03 am »

Hi,

I wrote a tool that uses UML scenarios to drive tests.
It discovers interfaces using introspection for COM objects, Web Interfaces, and .Net assemblies.

I am using exports of EA scenarios to generate the test templates, then override one or more actors with the TestTool to generate the tests.  

When I run the tests, initially they return "not implemented" and "not verified" because they contain pseudo code names for everything based on the object model names in EA.

I then manually map the pseudocode names to the discovered methods on the binary I wish to test. And manually add parameterization with a matrix override.  Hence a={1,2,3} and b={4,5,6} will generate nine test cases.  My paramiterization can use xpath assignments, and can apply to any node, entity, or defined variable.

Based on this work flow, it would be helpful if a requirement object had a schema that would accept a structured language definition:
<Requirement>
 <Capability></Capability>
 <Conditions>
   <Condition></Condition>
 </Conditions>
 <Constraints>
   <Constraint></Constraint>
 </Constraints>
 <Verifications>
   <Verify></Verify>
 </Verifications>
 <ModelLink></ModelLink>
</Requirement>

I could then autogenerate the condition validation steps and the verification steps directly from EA as well.

We express Conditions as pseudo states (i.e. Material.Present)  and Verifications as either conditions or assertions.

I haven't yet schematized the matrix paramiterization description.

10

General Board / Re: Requirements Engineering:Capability Types

« on: February 02, 2007, 03:25:58 pm »

I like your wiki.

I looked at the EA users wiki and started a topic under Best Practices for Requirements Engineering.

I started a basic outline detailing some activities that I do.

Since I am a newbie, I obviously don't know the best way to use EA for these things, but will document how I am discovering ways to do things. Presumably, y'all will feel free to tell me how I'm doing it all wrong.  ;-)

11

General Board / Re: Requirements Engineering:Capability Types

« on: February 02, 2007, 09:09:29 am »

Before the add-in makes sense, there has to be a way to extend the EA model for structured language and have a convenient way to enter the data.

Does anyone advocate data entry directly into the DB tables? Or are you using the import from CSV effectively to add new objects to the model from Excel?

12

General Board / Requirements Engineering:Capability Types

« on: February 01, 2007, 08:54:41 am »

I mentioned that I classify each requirement as one of six types. Here is how I use them to elicit more comprehensive descriptions of the requirement.

Transformation (TR) - simple algorithmic transformation further description requires a list of inputs, outputs and the transformation algorithm.

Synchronization (SY) - things in different domains must be kept in synch. Description requires one master, one or more slaves, data set, quality of service info including error case, synchronization event, frequency of synchronization.

Information Display (ID) - a specific case of SY where the slave is a GUI or Log.

Required Behavior (RB) - A behavior that must occur, typically expressed by a state machine or sequence diagram without external actors.

Commanded Behavior (CB) - An actor effects the bahavior assynchronously. Description requires a list of actors who can command it, the command, a reference to the underlying RB, a reference to a ID indicating how the actor knows the command has been accepted, or the RB performed.

Work Piece (WP) - a behavior where the changes made to a "thing" are tracked. Description requires identification of the "thing", stages of progress for the thing, and the data set associated with each stage of progress.

As I classify Natural Language descriptions of requirements, if I can classify a requirement into more than one type, then I split it into multiple requirements.

The law of diminishing returns applies, so I use judgement as to what detail is required to adequately describe the capability.

I recognize that there may be many other details that could be added to these, and I welcome your input.  But these are what I currently use to flush out more detail from the stakeholders.  

Ideally, I would like to use these to generate analysis views.  For instance, by collecting all the CBs associated with an actor, I can review the completeness of the actor's GUI interface.

Ideally, something in EA could generate the view for me. But I figure, worst case, I'll export stuff, massage it, and re-import it in a new view.  I haven't tried this yet, but I hope it works in EA.