archive-org.com » ORG » J » JEFFSUTHERLAND.ORG

Total: 379

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Business Procedures are not Represented Adequately
    responsibilities A separation into a business process layer and a business entity layer is easily to be done since business processes use business entities but not reversely 3 Separation of Data Access and Data Storage Layer As stated in section 2 the responsibility of a business entity is to provide services related to the business domain A business entity should not be concerned with the storage and retrieval of its data The data storage layer encapsulates the access to a specific data base Thatmeans it hides the design of the data base as well as the specifics of the data base access and retrieval language With a relational data base the storage layer consists mainly of SQL statements either of dynamically SQL statements that are interpreted or of prepared statements or of stored procedures which preprocessed and stored in the data base management system With a IMS host database the storage layer may consist of CICS transactions that contain IMS statements The objects of the data storage layer encapsulate this code They provide methods like a method retrieve account The data access layer is the link between the business entities and the storage layer It provides services to the business entity layer for creating a new business entity for creating a business entity that exists already in the data base and for updating and storing business entities For the implementation it uses services of the data storage layer In addition to the explicit creation of business entities on a request from the business entity layer the data access layer needs to perform an implicit creation when resolving references The problem is that a business entity which is being created may contain references to other business entities which are not yet created The business process layer requests the service from the data access layer to start a transaction or to terminate it The data access layers is responsible for the transaction management Typically it will not implement it on its own but use the transaction management of the database management system or of the DC system like CICS 4 Responsibility of Each Layer We allocate to each layer the responsibilities it has to fulfill and refer when existing to proven concepts or patterns that indicate how to implement a responsibility Here we give just a few examples in addition to the items presented regarding the separation of the layers For example consider consistency checks Field related consistency checks are a responsibility of the presentation layer The reason is that a user should have fast feedback after entering a wrong input in a field A user should not have to wait for feedback till all fields or a group of fields of a business entity are entered This responsibility should be implemented by providing domain specific editors as data entry and display widgets For example for each kind of accounts with a differently structured account number a specific account number editor should be provided Both field related checks and cross field consistency

    Original URL path: http://jeffsutherland.org/oopsla98/schmid2.html (2016-04-27)
    Open archived version from archive


  • <font size="+2"><b>Working with Business Objects: A Case Study
    several locations breaks have to be supervised such that for each break and location a teacher is present A teacher may have certain exclusion times where s he can not be present The mission is to design an application system that supports the school in scheduling the break supervision To be able to evaluate the workflow support of BOs we stipulated an exemplary workflow for the planning task After generating plans for each location the plans are combined and tuned into a resulting schedule This schedule has to be approved by the teacher s union in case some teachers have to work over time For the case of disapprovement the head of school can vote the union down Otherwise the schedule has to be tuned again This process is shown in figure 1 as an activity diagram To be able to evaluate the reuse support of BOs we stipulated the following scenario for the development of IT support at the school The planning component is acquired by the school from a component vendor that produced it as a general component to be adapted by different companies for their planning purposes This component supports the generation of plans based on given Resources and Timeslots It only includes a very limited workflow The adaption requires specialization of the Entity BOs of the component as well as the addition of further Process BOs according to the workflow associated with break planning It also requires the design of the functionality and the user interface for the break planning system After some time the school decides to buy a teacher administration system and now needs to integrate the existing break planning BOs with the BOs of this system In particular the administration of teachers in the break planning system has to be done by the new administration system and the payment of teachers in the administration system depends on information on supervised breaks Figure 1 The workflow activity diagramm 4 Experiences with BOCA CDL In the following we sketch the specification of the analysis model of the case study and our experiences with CDL The details can be found in Hor98 Entity BOs We have identified Plans and Resources as the Entity BOs of the generalized planning component which are specialized to BreakPlans and Teachers for the school application TimeSlots and ExclusionTimes are Dependents This was straightforward Some difficulties in the detailed specification of the operations of these BOs are collected at the end of this section Process BOs The workflows associated with planning were modeled as separate Process BOs The use of state sets was very convenient for modeling the different stages of the workflow In particular the specialization of the general Planning Workflow consisting of the stages Edited In Operation to the specialized Break Planning Workflow was elegantly captured by refining the state sets using the DURING construct Compared with UML the expressivitiy of state transitions in CDL has some minor flaws CDL state transitions do not have an action part Run time

    Original URL path: http://jeffsutherland.org/oopsla98/molterer.html (2016-04-27)
    Open archived version from archive

  • Which Business Objects
    s available from their immediate suppliers For example he could tell me not to order a particular monitor because it would take two weeks whereas another monitor was on hand and available in the warehouse of the local supplier On the other hand Dell is not perfect either You may not get the same warnings if you buy online as Jakob Nielsen learned I recently had to buy a new PC and tried to do so through Dell s website following my own rule that you must live a Web lifestyle yourself if you want to be an Internet pundit The Dell site had some weaknesses but it was reasonably easy to use and allowed me to order the desired high end machine Three days later I received a confirmation email stating that the machine was expected to ship 6 weeks later This was obviously not satisfactory when you order on the Internet Amazon com has trained users to expect a confirmation email within a few minutes and the product within a few days unless the website has warned them about shipping delays When I called up Dell I was told that the late delivery was because my requested tape drive was out of stock How about integrating your inventory system with your website folks Customers need to be told about delays and inventory problems while they are still researching their purchase online and can consider alternative options Outcome Dell lost a 3 035 order because their website delivered poor customer service http www useit com alertbox 980809 html Now should that integration include only the inventory at Dell or also their next tier of suppliers Chances are the tape drive was out of stock at the supplier Mass customization make to order The virtues of Dell s make to order business model have been described at length but here is a salient example Compaq which reported net income of 16 million about 5 percent of Dell s earnings in the first quarter on worldwide sales of 5 7 billion nearly 50 percent more than Dell s summarized the problem in its quarterly filing with the Securities and Exchange Commission In each product cycle we confront the risk of delays in production that could impact sales of newer products while we manage the inventory of older products and facilitate the sale of older inventory held by resellers Zero working capital Dell often gets paid for the computer before it is manufactured They probably pay suppliers after parts are used in a computer that has already been paid for Toys R Us owns almost none of the inventory on their shelves it s mostly on consignment only washing through their books at the cash register when it s purchased Dependent events Many business events are really stimulated by and dependent on other events Dependent demand is a concept introduced by Material Requirements Planning MRP systems in the 1960 s It means that the end use demands are the only independent demands

    Original URL path: http://jeffsutherland.org/oopsla98/haugen.html (2016-04-27)
    Open archived version from archive

  • 1
    Steve Marney EDS Intelligent Object Systems Dr Santanu Paul IBM Center for Software Engineering Wolfgang Schulze Dresden University of Technology 10 OO Business Rules and their Uses Agents and Workflow 15 60 people Benjamin Grosof IBM T J Watson Research Center grosof us ibm com Bei Tseng Bill Chu University of North Carolina at Charlotte Jarir Chaar IBM T J Watson Research Center Isabelle Rouvellou IBM T J Watson Research Center 11 Evaluating Object Oriented Design 20 30 people Robert Biddle Victoria University Mathematical and Computing Sciences robert mcs vuw ac nz Rick Mercer Penn State Berks Eugene Wallingford University of Northern Iowa 12 Pragmatic Issues in Framework Design 10 15 people David Laurance Lucent Technologies dlaurance lucent com Dave Williamson ObjecTime Ltd 13 Reflective Programming in C and Java 25 35 people Jean Charles Fabre Centre National de la Recherche Scientifique jean charles fabre laas fr Shigeru Chiba University of Tsukuba 14 Formal Underpinnings of the Java Paradigm 50 people Susan Eisenbach Imperial College se doc ic ac uk Jim Alves Foss University of Idaho Drew Dean Princeton University Sophia Drossopoulou Imperial College Tobias Nipkow Institut fuer Informatik Technische Universitaet Muenchen 15 Meta data and Active Object Model Pattern Mining 15 30 people Joseph W Yoder University of Illinois at Urbana Champaign j yoder uiuc edu Michel Tilman UniSys Dirk Riehle UBILAB Union Bank of Switzerland Martin Fowler Independent Consultant Brian Foote University of Illinois at Urbana Champaign Martine Devos Argo Monday 16 Agents of Change Half day 12 40 people John Daniels Bankers Trust Company jdaniels cix compulink co uk Laura Hill Sun Microsystems 17 Partitioning and Simulation of UML Models Half day 40 people Georg Beier Fachhochschule Mannheim University of Applied Sciences g beier fh mannheim de Mike Frankel Esprit Systems Consulting Inc 18 Object Technology and Product Lines 10 15 people Gary Chastek Software Engineering Institute gjc sei cmu edu Felix Bachmann Carnegie Bosch Institute Patrick Donohoe Software Engineering Institute 19 Formalizing UML Why How 30 people Luis Andrade OBLOG SA landrade oblog pt Ana Moreira Universidade Nova de Lisboa Akash R Deshpande University of California at Berkeley Stuart Kent University of Brighton 20 Thinking with Prototypes 15 20 people Antero Taivalsaari Sun Microsystems antero taivalsaari eng sun com James Noble Microsoft Research Institute 21 Habitability in a Virtual World What Constitutes Living Software 10 15 people Nancy Lewis ObjecTime nlewis objectime com David Laurance Lucent Technologies 22 Non Software Examples of Patterns of Software Architecture 10 20 people Michael Duell AG Communication Systems duellm agcs com Linda Rising AG Communication Systems Frank Buschmann Siemens AG Hans Rohnert Siemens AG Michael Stal Siemens AG Monday 23 Pattern Writers Workshop 32 40 people Jim Coplien Bell Laboratories cope bell labs com Frank Buschmann Siemens AG Richard Gabriel DreamSongs RPG Consultancy Christa Schwanninger Siemens AG 24 Use Case Patterns 10 20 people Paul Bramble AG Communication Systems bramblep agcs com Greg Gibson AG Communication Systems Alistair Cockburn Humans and Technology 25 Model Engineering Methods and Tools Integration with

    Original URL path: http://jeffsutherland.org/oopsla98/workshop_table.html (2016-04-27)
    Open archived version from archive

  • Agenda: OOPSLA'99 Business Object Component Workshop
    Process and an Abstraction Mechanism Islam Choudhury Dilip Patel Class Identification in Business Information Systems Francesco Capozza Sergio deCesare Maria Carmina di Canillo Model Purposes not Processes Chris Marshall Object Models Architectures and Frameworks An eXtensible Object Model for Business to Business eCommerce Systems J J Dubray Yuzo Fujishima P Curtin A Chaloori Object Oriented Architecture of Business Process Catalogue Pavel Hruby Business Components The Emergence of a Business Object

    Original URL path: http://jeffsutherland.org/oopsla99/agenda.html (2016-04-27)
    Open archived version from archive

  • From: Dilip [mailto:dilip@sbu
    Experience Report Pamela M Rostal 65 79 Business Processes are not represented adequately in Business Applications and Frameworks Hans Albrecht Schmid and Fernando Simonazzi 80 90 Are Workers Knowledge Rich Business Objects Nigel Phillips 91 105 A Dynamic Business Object Architecture for Bridging the Communication Gap between Business Management and IT Professionals Kitty Hung Matthias Kraner Srba Cvetkovic 106 120 Distributed Management of Component Framework Specification Junichi Suzuki and Yoshikazu

    Original URL path: http://jeffsutherland.org/oopsla99/earlypublish.html (2016-04-27)
    Open archived version from archive

  • Dubray: OOPSLA'99 Business Object Component Workshop
    refer to the class definition to handle its instances Referring to an external entity with proprietary encoding is an important issue in the development of highly distributed systems Objective C and SmallTalk have partially solved the problem by providing a semantic based method invocation However instance s data structure is still constrained to a class structure A key concept in the OMG distributed component specification 1 is to wrap messages into a rigid request and marshal all the arguments in the Semantic Data Object that is passed as a set of arguments with the request message The receiver processes the SDO to extract key value pairs The major issue with the approach is the maintenance of the SDOs code when the business object format evolves We suggest to model business objects after well formed XML documents 2 i e not necessarily associated with a schema The major benefit of this approach is that now the instance carries both data and data structure This approach features several benefits in a highly distributed environment like eBusiness One of the most innovative is instance evolution or extensibility In the OO world once an instance has been created its structure has been set in stone The only evolution possible is to create a new instance of a new Fig 3 The XOM Metamodel class or subclass then populate this new instance with some or all of the content of the original instance and finally delete the original instance Well formed XML documents can be appended with new data structure and data without loosing the integrity of the original instance This makes them both flexible and adaptive Instances of well formed XML documents XOM instances are concept that is hybrid between the concepts of Object and Documents You can access the data through a strict semantic and you can augment the data at run time like you would edit a document In addition to being distributable components in the OMG sense 1 XOM instances are also semantically accessible as opposed through an interface 2 3 You don t need to share the knowledge of all or part of the data structure to access the data you only need to share a common semantic Furthermore semantic translator can easily be built in the access layer in the case where the two systems would not share the same semantic The extensible object model has also some major design implications Application logic can be divided into methods e g data access methods workflow logic and services that wrap procedural logic and legacy systems into a simple document based interface Documents are passed to the services via a projection mechanism Unlike a database view a projection is a request specified semantically by a service and that will be applied to any document that will be passed by the workflow engine during a service invocation regardless its type or data structure The projection concept offers the loosest coupling between the application logic and the data model Instances can also be

    Original URL path: http://jeffsutherland.org/oopsla99/Dubray/dubray.html (2016-04-27)
    Open archived version from archive

  • Due: OOPSLA'99 Business Object Component Workshop
    e g one customer can have many orders but one order can only have one customer Yet there is no indication in this diagram of who establishes owns validates or maintains these relationships Neither is there any indication of the epoch or period of time for which these relationships hold true None of this mattered much during the past thirty years of independent green fields custom application development The invariants and epochs of these systems were typically small enough in scope to be assumed as common knowledge Over time however emerging large scale enterprise wide data modeling projects were delayed by weeks and even months in furious if fruitless debates over the semantics and business rules of what constituted a customer or an employee or a sale Instead of recognizing alternative viewpoints data modelers attempted to resolve multiple viewpoints into a single version of the truth There was simply no understanding that conflicting and even irrational viewpoints are unavoidable and often necessary within any organization The advent of reuse in the very large of common components or business objects requires that the invariants of the domain and their associated epochs be precisely specified in order to facilitate the reuse of appropriate components This precise specification however will be complicated by the existence of multiple and often conflicting viewpoints each of which have their own invariants and epochs For example in a business domain there may be several viewpoints that interpret the behavior of each object or collection of objects A financial accounting viewpoint may have significant differences in its invariants from a management accounting or a taxation accounting viewpoint Each of these viewpoints may be associated with different epochs or time related versions of these invariants One way of dealing with this situation that will hopefully eliminate the reenactment of the furious but futile debates of the data modelers in their search for the truth in their models is to Allow for Many Truths Allow For Many Truths If it swims like a duck and quacks like a duck and walks like a duck it doesn t have to know that it is a duck The duck entity just needs to behave Ornithologists biologists and little children will determine what is a duck from there own perspective Indeed the ornithologist parent of a little child may opt for kindness instead of truth by agreeing with his child that the duck is a duckie or even a swan Invariants that describe or define relationships among components and objects should be categorized according to viewpoint The same observer may have different viewpoints according the role they are currently playing as in the ornithologist parent above There should be no attempt to reconcile different viewpoint interpretations of behaviour There should be no futile quest to ultimately define the concept or Platonic form of duck Instead the invariants of a particular viewpoint must be encapsulated within that viewpoint Further these viewpoints must be arranged into the versions or the epoch of each viewpoint Perhaps

    Original URL path: http://jeffsutherland.org/oopsla99/Due/due.html (2016-04-27)
    Open archived version from archive