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 - bockfu

Pages: 1 2 3 [4]
General Board / Re: clarify intended practice for relating element
« on: November 06, 2015, 05:31:52 pm »


thank you @qwerty, that site has a good mix of the spec mixed with examples  and commentary.   Still ramping on the UML spec and trying to apply UML correctly, so all the tips help.  

@Geert you stated:

If you have two elements representing the same thing than you have one too many.

You should only ever have one element to represent one (aspect of a) thing.

Arn't there exceptions, for example, you may have an Actor and a component element with the same name.  The actor would be used in a Use Case Diagram and Component in Component diagrams.

General Board / Re: clarify intended practice for relating element
« on: November 04, 2015, 05:58:54 pm »
Despite the title the upper diagram is not a component diagram but a set of notes.


I agree, that's a horrible example.

This example from OMG UML spec 2.5 (document number formal/15-03-01) is both more illustrative then the first example and better representation of what might be found in a component diagram.

General Board / Re: clarify intended practice for relating element
« on: November 04, 2015, 05:45:59 pm »
my original question has been answered, thank you all for the dialog.  Here is a summary as I see it:

  • The trace association can be used to relate elements to one another.  Rationale from OMG UML spec Traces are mainly used for tracking requirements and changes across models.
  • Multiple elements modeling the same entity should be avoided.  Rationale is the different element types are intended to model different aspects of the system.  The intention of the model can be unclear and have added complexity if two elements are representing the same thing.

I have been using EA for several years, but rarely in a multi-user usage model.  A team of us will start using a common model and I am investigating what guard rails we should apply for how we work.

I found I had used class diagrams to illustrate the types of widgets via specialization/generalization, and component diagrams for how the widgets interface with one another.    This didn't seem right and I wanted to get input from other UML practitioners.

General Board / Re: clarify intended practice for relating element
« on: November 04, 2015, 05:41:07 am »
Geert - I concur.  I am trying to learn what the common practice is when modeling a system.  

Contrasting your response to the example shared here, I'll infer that the model shall avoid duplicate elements of different types.  Class elements may relate to component elements, but they are different elements, and used to model different structural aspects of the system.

General Board / clarify intended practice for relating elements
« on: November 01, 2015, 04:43:10 pm »
what is the intended practice for modeling different perspectives of the same entity?  

For example, what I have done is define a UML class element and specify associations and attributes.   Then if I want to show its connections to other elements, create an UML Component diagram.   Again, add provides/requires interface and other connections.

I would think there should be a way to associate the two elements if they are modeling the same entity.   The rationale is to have consistent names, reconcile and leverage each elements associations and attributes.    I haven't come across a way to do this.  

Anyone have pointers here?  

General Board / Re: best practice for baseline and target arch mod
« on: November 04, 2015, 06:18:34 pm »
I am also interested in learning common practices for this scenario.

From my observations, I suspect there is no ideal solution to model this today.  An approach would be to have the 'To Be' state modeled in the same project as the current 'As Is' state.  Where the 'To Be' Model does not share elements with the current model.

Over time the current state will change and move towards the To Be state and one could save baselines of the model over time as needed.  

General Board / Re: Recommendations for file with many packages?
« on: April 15, 2011, 07:35:18 am »
I am leaning towards option 1 for the reasons including the ones you stated.

After time there will be component specific Class or Data Models, but it all starts with the business process & requirements.  At time zero there are no components.  Adding the concept of 'component' is forcing the documentation into a box determined by an implementation.

Thank you.

General Board / Recommendations for file with many packages?
« on: April 14, 2011, 08:42:42 am »
I am on the verge of starting a new project and plan to use version control to enable multi-user collaboration of the eap file.

My question relates to what is the recommended package layout?  Is there a single best-practice or is this comperable to 'branch policies' where there are many valid practices, each having pluses and minus?

For example:

Given two complex software components to model, should packages be split by models or components?

Model approach:

+ Requirements Model
   - Component A
   - Component B
+ Use Case Model Model
   - Component A
   - Component B

Component approach:

+ Component A
   - Requirements Model
   - Use Case Model
+ Component B
   - Requirements Model
   - Use Case Model

In general the approach I plan on taking is to start simple and add the complexity and component scoping when necessary.

Any recommendations or pitfalls to watch out for?

Uml Process / Re: Unexpected diff:Activity Diagram vs. Dynamic V
« on: November 12, 2015, 04:41:25 pm »
Sparx support clarified via email to me the quicklinker options will be limited based on the diagram type.

In this case of the 'Dynamic View', the diagram type created is an Interaction Overview Diagram so it does not allow decisions to connect to Actions.

I still observed some unexpected behavior, but the diagram type clarifies some of it.

Uml Process / Unexpected diff:Activity Diagram vs. Dynamic View
« on: November 06, 2015, 06:36:15 pm »
I noticed some unexpected differences in what was allowed when editing an Activity Diagram and the default diagram created from the Dynamic View.

For example:
  • Create Dynamic View via Model Pattern
  • Create decision element
  • Using the arrow thingie (can't remember what EA calls it), create an action from the decision element via control flow

Expected Results:  select Action/Control Flow, new Action created and linked to decision.
Actual Results:  Menu does not provide an Action option

This seems like a bug.   Am I doing something wrong here?


Pages: 1 2 3 [4]