Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - DanG83616

Pages: 1 2 [3] 4 5 ... 13
31
General Board / Re: Is there anyway to process macro of C++ file ?
« on: November 20, 2010, 02:28:26 am »
[Deleted misleading comments about IDL code gen/import]
If you installed the MDG technology for Corba then IDL will appear in the language options for source code import. Make sure you used Add-ins->Corba to install the MDG technology. If you don't see Corba in the list then you also need to enable the add-in using Add-ins->Manage Add-ins. Even at this point, you will be faced with possible incompatibilities between MIDL and CORBA IDL.

Yet another idea for your primary goal is to just do a quick macro expansion using search-and-replace on a copy of strmif.h. The import source code feature is most valuable when you change the code before changing the design. Since strmif.h (and any other 3rd party lib interfaces you use) won't change very frequently the value of automatic import becomes much less significant.

32
General Board / Re: Is there anyway to process macro of C++ file ?
« on: November 19, 2010, 02:55:20 am »
You can run the C++ preprocessor on the files and then import the preprocessed code. It is inconvenient but not too bad for code that doesn't change.

You could try importing the MIDL files instead of the C++ files. I use CORBA idl and there is a free add-in for that. I don't know if it would work for MIDL but you could try it. This option will enable you to reference the interfaces and use the methods in sequence diagrams.

You might consider neglecting those interfaces altogether. It may be sufficient to model only the package dependency and not worry about the details of how your code uses the interface. For me, most of the modeling benefit is to clarify and verify the interfaces I'm designing. I get less benefit from modeling the interfaces I do not control. YMMV.

HTH, Dan

33
General Board / Re: Classes go in Class model or Component model?
« on: October 29, 2010, 07:34:46 am »
When creating new interfaces, I create the element directly in the project browser under the global interfaces package. I assign it to a flow port (essentially a public attribute of the component) by assigning it as the port classifier in my component diagram. For mode changing interfaces (pure virtual classes defining member functions) I add required and provided interfaces of the requisite type (from the global interfaces package).

Global Interfaces
  namespace
    interface
    interface
    interface
Global Classes
  namespace
     class
     class
Component Package
  Component Model
    Component diagram depicting the component by itself (pin-out diagram)
    Component element
      port1 (with classifier defined in the global interfaces package)
      port2
      port...
      partA (with classifier defined in Class package below)
      partB (with classifier defined in a global class package)
      part... (or classified by component classifier defined in another component package)
  Classes
     namespace
       namespace for this component
         class diagrams - primarily inheritance depictions
         class
         class
Compoent package
   ...
  
The parts attributed to the component can be classified by external classes or other components. When you do that you have and inter-package dependency. This of course is only practical and you'll take care to package those global classes carefully (they must not directly use internal classes). Thus, this component package will depend on the global interfaces package and a global class or component package.

This is just my way of doing things and is not pure. It is very much an implementation model can could be derived from a logical model. However, my skills progression goes like this:
Learn to write code that you can get to work
Learn to write code that you can test <-- lots of years at this plateau
Learn to write code that you can model <-- recent accomplishment
Learn to write models that map to code <-- " "
Learn to write requirements that you can allocate to your model <-- working on it
Learn to write models that you can model... <-- aspiring to

Dan

34
General Board / Re: Classes go in Class model or Component model?
« on: October 29, 2010, 01:22:13 am »
I use component diagram to depict the names of external interfaces and composite diagrams to show control and data flow interconnection between the subcomponent instances. I find these two representations, along with state charts, to be the most useful diagrams for design specification to be used for coding and maintenance.

I use class diagrams while figuring out the decomposition but a class diagram tends to be a temporary document for me. The complete details of a class are more easily expressed in my target language (C++) than in UML. It is easier to express the details, compile and then import the detailed class descriptions when I what to see class structure. I miss out on using class diagrams to express constraints so I'm studying that usage.

You should Google Leon Starr, though. He has a good blog article (and a book I have not read) about clearly expressing constraints in class diagrams. This seems like the very best purpose of a class diagram yet I seldom see them used to this full advantage.

TIFWIIW,
Dan

35
General Board / Re: Cross-package dependencies
« on: October 27, 2010, 05:47:10 pm »
We use version controlled packages. We have to be really careful to make sure that packages are added to a private project in bottom-to-top order. Above all, before checking in a changed package, make sure that all of its referenced packages have also been loaded.

Let's say you have package A and it depends on B. You might need to make a change to A that doesn't involve and of the relationships to B. You make a quick private project and check out A, make the change and check it in. You just LOST all A's references to B!

I don't have a clever way around this and have been getting by okay by just being careful. It is probably possible to write an script that you can use to check for unresolved references before checking in. I bet Geert could whip that out in minutes!

I thought I was clever and created a package dependency diagram for each of my packages. Not a bad idea regardless of the VC issue. Unfortunately, that diagram is not a guide. If a package is not loaded then the diagram just doesn't show the package. Pretty useless if you don't already know what packages should be there.

Despite this risk of losing references, the solution has been workable.

As Geert said, avoid cycles. You'll really want to do that anyway so whatever trouble EA gives you with resolving cycles is just one more concrete reason to not have cycles. We package each component in its own package and interfaces are not allowed in component packages. They are packaged separately so that it is easier to avoid cycles. Two components packages that might otherwise depend on each other only depend on an interface package instead.

We have components that are nothing more than assemblies of other components. These packages don't have any actual classes in them but hold the component definition and composite diagram for the assembly component as well as interaction diagrams. This keeps the dependencies formally going in one direction.

HTH,
Dan

37
General Board / Re: Including a table in requirements
« on: October 20, 2010, 02:42:20 pm »
I've tried pasting rtf tables into the notes of a requirement element but it didn't work. I almost posted a request for it the other day but decided I didn't really want it after all. Usually a table is used to group requirements for reading. Each row in the table is usually a single requirement so I decided it is better to use document generation to create the table. You might still want the feature but I figured I'd share my conclusion just in case it might help.

Dan

38
General Board / Re: how to manage a model over multiple phases
« on: October 19, 2010, 01:41:32 am »
Oops. Fred, I should have addressed my last post to Ali. I didn't make my point clear. If the project is to overlap phases then a component that is new in one phase might need to be identified as existing in the next all at the same time. Fred's solution would address that by labeling the components with project information.

I'd recommend against labeling components with project information. Another way is to organize folders in the project browser to hold components by phase. Place the component in the phase that it will be developed (phase 0 holds preexisting components, perhaps). That would allow you to use the Phase field to indicate the status of the component and the folders to generate reports indicating component state according to plan.

I get picky about mixing project information into the component models because I reuse the models in more than one project. If the components will only be used in the one project then it probably doesn't hurt to mingle project attributes with component attributes. In that case, Fred's suggestion is less complicated and should work fine.

Dan

39
General Board / Re: how to manage a model over multiple phases
« on: October 17, 2010, 03:42:14 pm »
If a component isn't existing yet then it is still new. When it exists then is exists in every configuration it is used. It seems odd that a component would be new and existing at the same time. If your goal is to indicate which phase a component is expected to reach the "existing" state, then phase would seem like a good attribute. However, you might just do better keeping a separate plan listing the which components you expect to complete in which phase and not try to attach the project plan attributes directly to components.

I have a model for each component and include those in models that use them. Each component is independently version controlled as are the assembly models. The trick to this approach is that you need to make sure your subcomponents are encapsulated. If you start defining a component by the other components it interacts this approach won't work. You can avoid doing that. Assemblies are made up of instances of components and those instances go in the assembly model so there is no need to have the classifier definitions referencing each other. I don't use the version, state and phase attributes but if I did I'd make sure they apply to the artifacts themselves and not the system or project within which they are utilized.

I probably didn't directly help but maybe gave you some ideas to consider.

Dan

40
General Board / Re: Using EA with Agile
« on: October 12, 2010, 02:51:33 am »
Traditionally, documentation is not needed for the feature but is nice to have later when more features are to be added. If the sprint is focused on doing only what is necessary to get the features delivered, I can see modeling tasks building up in the back-log.

An effective modeler will use modeling activity to produce more features sooner. In that sense, modeling doesn't have to be a required part of the package; it is just a side effect of effective and efficient development practice. This depends on good modeling skills which for most developers are not instinctive.

Does it work to "lay down the law" and force all features to be modeled, even if the developer is not yet skilled? Is there another way to incorporate modeling?

I'm hoping to resolve apparent conflict between modeling and the following Agile values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation

When schedules are tight (always) the left side is all that is done and the right side is a nice-to-have thing that "in a perfect world" would be also done. I don't want to be cynical I believe I'm only being a realist. Geert seems to have a good measure of control over defining his process. What about others who have less control? I would be very good to find a clear and logical resolution to the apparent conflict.

Dan

41
General Board / Re: Using EA with Agile
« on: October 09, 2010, 02:20:27 am »
I hope there are some constructive suggestions to this thread. My organization is going to use Scrum because, well, "everyone's doin' it." Since I have not achieved 100% code gen from models I fear modeling will be viewed as non-agile. It would be great to hear how I can continue modeling even when "working code" is the only measure.

42
General Board / Re: Willful Transition Lines
« on: October 08, 2010, 03:32:16 am »
Thanks, Roy. I had been using custom line time but the trick is to put a control point in the line. You move the control point and the line goes with. All this time I've been messing with the ends only.

Bezier doesn't move the start end.

43
General Board / Willful Transition Lines
« on: October 07, 2010, 04:31:17 am »
I have a pattern that involves a super state transition to sub state. I drag the transition from the super state and EA happily draws the arrow. Unfortunately, this arrow has a mind of its own and is not easily made to conform to my aesthetic desires. There is some amount of predictable behavior but not much. The only way I've been able to get the look I desire is to "walk" the arrow into position by alternately pinning and unpinning the ends until it is position. Does anyone have a usable technique?

Thanks,
Dan

44
General Board / Re: What exactly is:  Executable UML
« on: October 08, 2010, 12:59:15 am »
I don't mean to be glib but if you use google you'll get plenty of hits. It is the latest trade name for the Shlaer-Mellor approach to software development.

I think the lack of serious response from this forum is because EA can be used to create models that could be compiled by a Executable UML model compiler but EA doesn't include such a compiler.

IMAO, if you don't know what it is then you are years and many $$ away from making effective use of it. This is no judgement on you but a reflection of my own experience. YMMV.

HTH,
Dan

45
General Board / Making Hidden Transitions Reappear
« on: October 07, 2010, 04:40:16 am »
I have lots of transitions that happen to go between the same two states in a state chart. I would rather not see every one of the lines but do want to see the transition specification (event, guard, action) for each. Is there an easy way to achieve this goal? Carefully placing the lines on top of each other is NOT it.

One misguided attempt was to hide all but one transition. Of course, that hides the specification as well and doesn't work. Is there a way to recover from that mistake and make the transition visible again?

Thanks,
Dan

Pages: 1 2 [3] 4 5 ... 13