No subject

of time to create a relationship (e.g. by connecting them together with a
relationship tool and two mouse clicks), but when you add a property, the true
domain or counterpart entity of the property may be left undefined until
later.  When we have a graphical interface, we need a way to view only include
the entities and relationships we care about, because otherwise the resulting
network can be a nightmare to comprehend.

By the way, when I said text user interface, I meant a command line interface
for low level testing purposes.  If we are going to build a real user
interface, it should be graphical. 

- Mark


Luke Call wrote:
> 
> With adjustments & hopefully much learned from Mark and Tom's messages
> on modeling, here is another try at a use case list. If this is OK for
> now we can begin to add details to each use case, and do a domain model.
> Thoughts??  There are still issues with relationships between objects,
> and I'm sure an expert would do this differently, but I feel a need to
> move on. I suppose these need to be detailed out by stepping through the
> scenarios & seeing how each one would be handled.
> 
> The main thing here is for anyone to consider what they would add, to
> the basic list of user-oriented features for our phase one product.
> 
> Possible Use Case List for Phase 1:
> ----------------------------------
> -system startup (load data, prompt user)
> -add new object
> -enter name
> -add property [could be a relationship, or not]
> -choose type ["basic"/atomic, or object/class thing]
> -edit property
> -delete property
> -delete object
> -navigate (through relationships between objects & properties)
> 
> Luke
> 
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list

-- 
Mark Butler	       ( butlerm at middle.net )
Software Engineer  
Epic Systems              
(801)-451-4583