UH2@psuvm.psu.edu (Lee Sailer) (02/06/90)
In article <19320@grebyn.com>, schultz@grebyn.com (Ronald) says: > >My personal experience involves the development of a business >model for the company I work for. Using Smalltalk/V 286 as a >modeling environment, we have defined objects such as: > > o CEO > o CFO > o Accounting > o Accounting Clerk > o IRM > o Contracts > o Business Procedures > o Competitors > o Services > o Phones > o Communication trunk lines > o Application Systems > o Databases >... > >Associated with each of the above objects are appropriate >methods. For my CEO object I have methods such as Conduct >Meetings, Meet with Customer, Call CFO , Reorganize Company, >Create New Line Division, Travel to Meet Customer, Approve >Policy, and Do Daily Routine to name just a few. Associated with >most objects are required, or private methods, to identify and >track service levels. Is the object available, how much of it >is available, how often has it been available when some other >object has requested it, ..? I think this is interesting. But what advantages do you get over the traditional Structured Analysis toolkit, namely Data Flow Diagrams and Logical Data Models (aka ER models, SD Models, etc.)? The OO models are accurate, but it is hard to draw a picture of the CEO holding a meeting, or creating a new business. That's what the DFD's do best. This distinction between accuracy and clarity reminds me a little of the Semantic Data Model. This is a method for describing all the types of facts most logical data modeling techniques allow, and then a bunch of others. The problem with it is that it is entirely textual, with the main problem there being that novices (typically clients) have a hard time reading them. Thus, convergence of opinion between the modelers and modelees is harder to come by. lee