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".
  • Thinking Things
    people Examples of possible applications are private or public calendars PIMs ticket reservation and purchase systems document editors libraries of structured and or active documents systems supporting team work project planning and controlling systems but also conceptual models of natural systems in the field of biology medicine physics chemistry relevant sample data and experiments with them The knowledge about the behavior of the T2s included in the application will be a kind of software shared from the WWM while the concrete T2s in the application will be a kind of database or application data Since the software will be shared from WWM the application will be operated always by the most up to date knowledge Publishing knowledge as T2 will enable seamless cooperation and exchange of information between expert and researchers in a very native interoperable form not just in the form of texts an papers For example with a published proposal of a conceptual model in the field of high energy by one researcher his colleagues world wide will be able to experiment with their own data and hence proof or reject the proposed concept By such a cooperation the WWM will include still more and more knowledge proved by other researchers or users Still alternate knowledge different opinion about the same concepts will be possible The object model of T2 and the execution environment of T2 includes identity kind attributes associations compositions whole and parts state abilities methods actions constraints rules laws events body spatial features environment and inheritance prototype based Every important property of real world which cannot be described by a combination of other already existing properties has its conterparty included in the model The model is open in order to be able to accomodate possible new quality in the future Thinking Things will reside on

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


  • Introduction
    Still the problem in this area also well documented reference to Coplien interaction between frameworks Clearly our experience showed the need of standardization in this area which had begun to materialize ASF diagram of the patterns relationships Thru the knowledge sharing initiative we established Pattern movement across several lines of business The user groups were formed and the review of the design and domain patterns became a routine activity during these meetings The groups not only reviewed and studied the design and analysis patterns they also tried to establish the patterns technical and domain catalogs One of the major outcome from one of these meetings came the concern for lack of business patterns on the market While the awareness of patterns brought the realization of proven design techniques for specific technical design resolutions there were hardly anything in a public domain to help resolve the business problems such as designing insurance underwriting component or claim processing component Two patterns from GOF specifically were used in several projects to standardize the interfaces for redundant information For example in the institutional business area we had several different systems that had dealt with eligibility enrollment process Facade and Adopter patterns were introduced to deal with the common interfaces to the multiple problem domains while reengineering the multiple sub systems and replacing it with the common component As mentioned above the design patterns helped dealing with the interfaces however the bulk of the problem is reengineering of the business problem which had not been widely addressed by the pattern community nor by any other communities known to us The search for commonality lead us to the area of standardization at the meantime We established the participation in the forums where the standardization for the industries was considered to be the primary objective Among the groups we participated were OMG and Acord Both of these groups were involved in resolving the business problems as we perceived them One area of the OMG attracted our attention since it was dealing with the most emergent issue as we defined it Business Objects We had to establish the project charter of the importance of this concept to us primarily from the business stand point of view Business Drivers How do the business objects and or business patterns could help the application development community Again the answer is the reuse but not widgets but coarse grained business object components frameworks The challenge was to illustrate it from the specific business problem The application based approach to software development arose during the period in which business problems were relatively stable and software was relatively simple Under these conditions a software solution could be developed fairly rapidly to address any given business problem and the solution could remain to be valid for some years before being retired in favor of a new and better solution Neither of these conditions holds today Business conditions are becoming increasingly volatile and software is becoming ever more complex and difficult to develop The results of

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

  • Complex Adaptive Systems and Business Objects
    with the following interfaces the basic business object interface with its attributes getters and setters the persistence interface for storing and retrieving objects from the database the GUI interface used to display the object to its human observer A third party workflow program had been purchased to allow user input of business rules so that as more complex services were delivered their behavior would remain more responsive to changes in the business environment Because it was not used in the initial deliverable and there was some ambiguity about exactly which responsibilities it would fulfill the architecture evolved away from its monolithic set of workflows and business processes Instead each business object evolved a lifecycle that reflected its allowable states the triggers that caused state changes and the conditions under which the triggers fired Lifecycles With the advent of the second release analysis showed that business rules had been tucked into a variety of places such as stored procedures in the database in interface code in code executed by the Delegator whose responsibility was supposed to have involved only passing business objects from one package to another Delivery of additional functionality would only aggravate the difficulties posed by the distributed code so the decision was made to refactor A new interface was developed for each business object its service interface as defined in LECOMTE 97 governed by the object s lifecycle The lifecycle is designed to be the container for all business rules whether they are to be evaluated at the user interface or in the middle layer It consists of two groups a group of actions each constrained by a set of conditions and a group of audits that represent the object s current state as a function of its history The condition group can contain simple conditions or groups of conditions joined by a logical and or a logical or Each condition compares a specified property to a target constant the value of another property the sum quotient remainder or product of several properties combined Therefore each condition has a property group of one or more properties that must be evaluated Each condition can evaluate to true false or unknown if the property cannot be found on the specified object but its evaluation is required usually an indication that corruption has occurred Currently an external object asks the business object s lifecycle if its owner can perform a certain action If so the external object triggers the business object s method If any condition fails it is returned as the unmet condition and the return code is its failure return code In the next release the command interface should be developed well enough so that the external object can specify the action and pass control to the business object for evaluation of its lifecycle and performance of the specified action At that time unmet conditions will trigger alternate actions so that the business object never has to return control to the outside without coming to some valid intermediate or

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

  • Building Workflow Objects
    the ApproveRequest activity A workflow activity has several facets it serves as an adapter that enables composition of workflows from other workflow components and as a representation of a process step in the underlying process model it is an atomic unit from a monitoring and resource assignment perspective From an interoperability perspective a workflow activity represent an adapter for a workflow component that implements the activity the WfActivity interface specializes the WfRequester interface and can be registered with a workflow process which performs the work requested by the activity The context of the activity defines the context of that process the result produced by the process defines the result of the activity and the activity is completed when it receives a completion notification from the associated process Activity adapters can be used to realize distribution of complex workflow across business domain boundaries the main process delegates execution of parts of the overall process model to sub processes that interact with the main process using activity adapters The activity requester process pattern is very useful to decouple elemental requests for work in a process from their implementation it allows for replacement of an activity implementation without affecting the main process see the section on Implementing Process Steps for a more detailed discussion It is important to note that not all activities must be associated with a workflow process implementation The requester process pattern is used when there is a need for explicit delegation of the execution of the task represented by an activity to an entity that is potentially outside of the scope of the workflow process owning the activity Alternatively an activity can be implemented by an application that uses explicit operations on the WfActivity interface to set activity results and to complete the activity see the discussion activity implementations in the section on Building Workflow Applications Workflow activities can be associated with resources that are required to perform the work request represented by the activity This can be used e g to assign an entity in an organization model that is responsible for execution of a process step From a workflow monitoring perspective workflow activities describe the internals of a workflow process as far as these internals are exposed by jointFlow for each process step in the underlying workflow process model there is one workflow activity representing that step The full status of a workflow process is given by the overall state of the WfProcess and the states of all of its WfActivities An activity is the smallest observable entity in a workflow process Status changes and changes in the resource assignment of an activity are reported via event audit records status change event can also be published as structured events using the OMG Notification Service to other process observers Figure 3 Workflow Composition and Resource Assignment Resource Assignment A WfAssignment represents the association of an activity with a workflow resource several resources can be assigned to an activity and the same resource can be assigned to several activities The status attribute of an assignment can be used to indicate the specific nature of the assignment The set of WfAssignments associated with an activity basically defines the resources the activity needs to perform its task these resources are used by the implementation of the activity Resources may include people that provide input for the process step e g a clerk providing a credit assessment for an EvaluateCredit process step IT resources e g a server needed to execute an application or information resources e g a CAD document that needs to be made available to perform a task Workflow assignments can be used to realize various collaboration patterns of workflow participants for example different participants could contribute to the overall result of an activity or an activity might be offered to potential contributors assuming that one of them will take responsibility for execution of the work request Coordination of the resources associated with an activity is left to the implementation of the activity or its owning process Workflow assignments can also be used to realize work lists for people involved in workflow process execution the work list of a person would show a list of all WfAssignment associated with the resource representing that person The WfResource interface is implemented by resources involved in processing of workflow processes it serves as a generic place holder for an entity in a resource model and is expected to be specialized by implementations of the Workflow Management Facility potentially using a Resource Management Facility Specification of a resource model as well as definition of resource assignment rules is outside of the scope of the jointFlow specification see the section on Building Workflow Applications for a discussion on resource selection Process Monitoring and Auditing The WfEventAudit interface defines the information to be recorded when a workflow process or an activity changes its state e g activity ApproveRequest completed subtypes of the interface are defined for specific types of status changes execution state context or result attributes resource assignment A mapping of event audits to structured events as defined by the OMG Notification Service is defined to allow publication of workflow events workflow processes and activities are StructuredEventPushSuppliers WfEventAudit entities represent persistent versions of these structured events that can be retrieved for analysis later Event audit entities are associated with the source of the event the set of events produced by a process or activity constitutes the execution history of the workflow entity The lifetime of an workflow audit entity is not limited by that of its source this allows for analysis of workflow process performance history Workflow events can be used for monitoring and auditing of workflow performance The current state of a workflow process can be obtained from status attributes of the WfProcess and its associated WfActivities navigating the relationships between process and its activities The notification mechanism can be used to observe updates of the process status via consumers of structured events StructuredEventPushConsumers or StructuredEventPullConsumers as defined by the Notification Service The execution history of a particular workflow process can be explored by navigating the relations between a process manager and its associated workflow processes or between a process and its associated activities to obtain history information about the various entities involved in process execution Building Workflow Applications The jointFlow specification defines interfaces of a framework for realization of workflow process models It defines the interfaces necessary to enable interoperability of workflow process components workflow monitoring and for linking workflow components to resources involved in a workflow process It does not define details of interaction of the workflow entities that are irrelevant in support of these goals this allows for a broad spectrum of implementation of the WfM Facility and enables e g workflow processes realized in a classical Workflow Management System to interoperate with workflow process components developed as autonomous business components The following discusses options for the implementation of this framework and exploitation of the framework for realization of workflow applications Workflow Business Objects As discussed in the introduction workflow components are business objects jointFlow intentionally does not address the general aspects of business component management and focusses on the specifics of workflow business components Since the work in OMG on the definition of a base framework for business components has not been finished yet jointFlow uses a very simple business component model that serves as a place holder for a future OMG Business Component Framework specification basically all jointFlow entities are transactional identifiable life cycle objects and relationships between entities are realized using a generic pattern for enabling relationship navigation The basic assumption is that workflow components will be deployed in a business component infrastructure which provides mechanisms for efficient management of persistent secure transactional entities and enables interaction between independently developed business components We refrain from speculating about the shape of this infrastructure here but will discuss potential applications of some of the concepts defined in the Business Object Interoperability Framework proposal OMG98c and in the Enterprise Java Beans specification EJB98 in the following sections In an EJB infrastructure for example the entities defined by jointFlow would be entity beans that are deployed into EJB containers containers could take care of the persistent state of workflow processes activities assignments and event audit entities providing different back ends for these entities The container model basically enables deployment of the realization of a workflow process model into different runtime environments see also the discussion on workflow process implementation in the next section enabling reuse of workflow processes in different installations EJB homes would enable applications to create and locate workflow entities this could be used for example to realize process history analysis applications using specialized find operations on the home of workflow event audit entities The concepts for enabling interaction of business components defined in the Interoperability Framework could be used for integration between workflow components and other business components Workflow components could be used as building blocks for business applications e g to delegate execution of a complex operation in an application to a workflow process and of course business components can be used to implement process steps in a workflow process see the discussion of process step implementations below Implementing Workflow Process Models From a jointFlow perspective an instance of a process model is represented by a workflow process and its associated workflow activities it is assumed that these entities cooperate to realize the process goal according to the business rules defined in the underlying process model The jointFlow specification does not define details of interaction between workflow process and activities since this is not relevant for workflow interoperability the realization of this interaction is left to implementations of the Workflow Management Facility The following discusses several options for the representation of workflow process models in the jointFlow framework Workflow Engine Backends A Workflow Management Facility can be realized based on existing workflow management systems WfMS Execution of a workflow process by a WfMS is driven by a generic workflow engine that interprets the workflow process model at runtime in order to create and enact workflow instances In this scenario the WfMS takes care of the persistent state of the workflow components The workflow engine interprets the workflow process model and coordinates status changes of the associated workflow process and its activities see scenario A in Figure 4 In this model the workflow entities have no knowledge about the underlying process model they pass on status change requests to the backend engine which determines the resulting status changes and updates the corresponding entities A process start request for example would be received by a WfProcess passed on to the backend which decides which activities should be activated initializes their context changes their status potentially requests instantiation of other workflow processes that implement activities and waits for future status change reports from these activities Event Audit records and publication of status changes via notification can be handled by the WfMS backend or can be left to individual workflow components since this requires only local knowledge about the specific entity A WfMS often provides capabilities to maintain process history information this facility can be used to hold the persistent state of WfEventAudit entities Figure 4 Workflow Component Interaction Models Distributed Workflow Components Workflow processes and activities can be implemented as business objects that encapsulate the process logic of the underlying workflow process model Code generators might be used to translate the process model into a set of templates for workflow components There are various options for distribution of processing logic between the workflow process component and its workflow activity components and for realization of information exchange between these components Information exchange between the workflow entities can be realized via a private interface extending the WfProcess and WfActivity interfaces interface with operation to signal status changes alternatively the Notification Service can be used for this communication by specializing the WfProcess and WfActivity interfaces into StructuredEventPushConsumers that register their interest in status changes change events published by related workflow entities WfProcess and WfActivity are StructuredEventPushSuppliers Another option would be to use the managed relationships mechanism proposed in OMG98c where business components on the two ends of a relationship exchange information about their respective status changes There are several potential models for distribution of the process logic defined in the underlying workflow process model we discuss two variants in more detail Central Process Control In this scenario see scenario B in Figure 4 the process coordination logic is implemented by the WfProcess which creates WfActivities as required and determines when to activate them The workflow activities maintain their own state create event audit entities as required and are responsible for execution of a process step this may involve interaction with another workflow process that implements the process step However activities have no knowledge about other process steps When an activity is activated the workflow process initializes its context and waits for the activity to come back with a notification that it is completed it uses the result of the activity to determine follow on activities Distributed Process Control In this scenario see scenario C in Figure 4 the process logic is pushed down to the activities in a workflow process the workflow process and its activities publish information about their status changes e g their completion and the results produced Other activities are prepared to receive status updates an activation condition of an activity could determine whether or not to activate the activity when it receives information about completion of another activity Status changes of the process would be propagated to activities and might trigger status changes too The workflow process would use status updates from activities to determine when the process is completed Implementing Process Steps The jointFlow specification basically provides two ways for realization of a workflow activity if there is a need for loose coupling between the activity and its implementation the activity would be implemented by another remote workflow process otherwise it can be implemented by a local component In both cases the underlying workflow process model can provide information to be used to identify the components to be used to implement the activity The following discusses details of interactions of a request for work to be done within the context of a workflow process with components that do the work Workflow Process implementation The activity adapter enables composition of independently developed autonomous workflow components The requester process pattern defines the interaction between the components the activity specialization of a requester serves as a process context specific mediator between the main process and other workflow components The decoupling of main process and its workflow components makes it easy to change one side of the interaction equation with out affecting the other one the realization of the process step can be modified as long as it still provides the service requested by the activity changes in the main process can be hidden from the process step implementation by changing the activity adapter accordingly The role of the activity in this interaction is to Find an appropriate workflow component that realizes the process step Initialize the remote workflow process using context data of the main process and start it While the remote process is active propagate changes of activity execution state to the remote process and observe status changes of the remote process When the remote process to signals its completion translate the results of the remote process into process attributes of the main process and signal completion of the process step The underlying workflow process model will provide information on how to find an appropriate workflow process manager for realization of the process step Often this will simply be the identifier of a particular workflow process type represented by a WfProcessManager in this case the activity would locate the process manager using e g the CORBA Naming Service or an EJB process manager home using the identifier of the home and that of the particular process manager If greater flexibility in selecting a process manager is required advanced locator facilities such as the OMG Trading Service could be applied using selection criteria defined by the underlying process model The activity adapter can use the meta information about the context and result attributes of the remote process to translate between the context of the main process and the requirements of the remote process It is important to note that any business component implementing the WfProcess interface can be used as an activity implementation this basically means that it must provide operations to initialize and start it and it must signal its completion back to the requester The component might for example represent a wrapper for a legacy application in this case it would not contain any activities and would have a very simple state model running and completed In an EJB environment the home of the component could realize the process manager interface The jointFlow specification allows realization of this kind of workflow process faker to enable integration of a broad range of process components into workflow applications Business Component implementation The requester process pattern is used for interactions between an activity and components outside of the scope of the main workflow process In many cases a process step can be realized by an application within the scope of the workflow process In this case there is no need to associate a WfProcess with the corresponding activity instead the implementation of the process step uses operations of the WfActivity interface to obtain the activity context perform its task set the result of the activity and signal completion of the process step Often the work requested by an activity can be performed by an operation on an existing business component in this case the implementation of the activity can be derived from information provided in the underlying process model The pattern would be the following The process model contains information on how to find the appropriate component and which operation to invoke in the case of an EJB entity bean the identifier

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

  • A Goal-based Model of Coordination in Interoperating Workflows
    formal procedure for identifying which activities performed by which actors or more generally roles are the logically necessary predecessors of other activities Trigger modeling is a rigorous analysis of manual processes typically performed in order to obtain a formal definition of work being performed prior to entry into a WFMS A portion of a conventional trigger model for the manufacturing case described later in this chapter is shown in Figure 1 In Figure 1 the work activities such as Cut Vest Batch are constrained not to begin until triggered by semaphores from prior processes t1 through t5 that indicate preconditions have been satisfied The semaphores themselves are called triggers Trigger models are isomorphic to Petri nets and following work analysis the trigger model can be directly translated to a Petri net for formal analyses of correctness and completeness 3 Abstract Context of the Coordination Model Trigger modeling has traditionally been used in the context of a single work site Additional complexities arise when triggers are required between WFMS at different sites with potentially different views of how a given process should be performed With reference to Figure 2 process A is dependent on multiple autonomous subprocesses The dependency is both for the final product of the subprocesses and for coordinating communications at intermediate points within the subprocesses which enable various efficiencies principally scheduling efficiencies The timing of the coordinating communications are specified in terms of a process state trigger state as A understands the production process However B may change process definition dynamically This will result in mis timing or disappearance of the coordinating communications with process A The processes will become uncoordinated unless the trigger state can be reinterpreted in terms of the new process definition The problem is to place the coordinating trigger in the altered definitions at positions that would be considered equivalent by both A and B to the position occupied by the trigger in the original definition An exact match to the original position cannot be found and so a semantically similar positioning must be inferred from an interpretation of the incomplete information contained in the process models 4 Goal Based Coordination Model The basis of our coordination model is a work definition WD that specifies a hierarchy of intentions goals for the activities of a work process Figure 3 illustrates the WD used by the model The root goal is the overall purpose of the work process and the name by which the work is commonly known in the organization The layer of subgoals is generated during process design or specification and represents a process of stepwise decomposition of the root goal into its components 5 When the subgoals are well enough defined to be implemented they are linked to the generalized functionality by which they will be enacted Incorporating the concept of functions into the WD more closely models the manner in which workers conceive their activities than use of goals alone 4 The terminal leaf nodes of the WD are the actual

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

  • oopsla98_hung
    SMP The checklists should be reviewed and updated periodically to reflect the degree of performance improvement The SMP assessment is to be rolled over through the Dynamic Systems Development Method DSDM an iterative prototyping lifecycle environment where business end users and software developers work closely together 4 1 2 Business Process Level The second level is the business process level where business processes are annotated to support specific strategies through the process improvement technique using the ISO9000 standard operating business procedures to identify and define the tasks and actions needed to achieve the goals as set in the SMP 4 1 3 Object oriented Modelling Level The third level is the object oriented OO modelling level where object models are developed based on the business processes using the Unified Modelling Language UML notations Business processes are modelled by UML notation By this stage objects and classes have emerged corresponding to the key data storage concepts and generic business procedure components essential to the business in question These are demonstrably reusable across the various business strands captured through a series of case study projects 4 1 4 DBMS and Legacy Systems Level The fourth level is the database management system level a substrate of legacy and or non legacy information systems which must interface with the OO layer in the BO in order to allow data take on and system configuration and integration with hybrid OO and Non OO 4 2 Business Object Architecture Development The Business Object Architecture BOA as illustrated in Figure 2 is the framework in which individual BO s are related according to the common strategies processes objects and database stored in their own repositories thereby promoting the reuse of software components business processes and business strategies within a business domain Figure 2 Business Object Architecture 4 3 Dynamic Business Object Architecture Development The Dynamic Systems Development Method DSDM lifecycle provides an environment for BOA development An integrated approach is proposed and a DBOA is illustrated in Figure 3 Development phase is divided into five time boxes namely Figure 3 Dynamic Business Object Architecture 4 3 1 Time box 1 Feasibility Study Business management personnel do the pre project SMP checklist manual assessment exercise to reflect the current situation before meeting the business objectives The function point table is created in this phase 4 3 2 Time box 2 Business Study As a result of the pre project SMP checklist manual assessment those strategic factors not meeting the business objectives would be fed forward to the ISO9000 Standard Operating Procedures for Business Processes document The business processes are strongly linked to the objectives to meet The Object oriented analysis design UML standard notations are used to model the business processes 4 3 3 Time box 3 Functional Prototype A prototype is created with the functionality enough for the users to test Users are allowed to change their business requirements Users feedback is collected and application will be modified for the next prototyping testing Design models and documentation are also updated in accordance with the user requirement changes 4 3 4 Time box 4 Design Prototype By this stage the application should have all the functionality agreed in the project Since time boxing control is to ensure project will be delivered on time and within budget in the design prototyping stage users are not allowed to change their business requirements However they can require changes in screen handling and user interface design 4 3 5 Time box 5 Implementation The activities in time box 5 include system debugging user acceptance testing user training system integration configuration and system goes live 4 3 6 Post project review The post project review should take place 2 3 months after the system has gone live to allow enough time to evaluate the business performance against the business goals Business management personnel carry out a post project SMP checklist manual assessment exercise Any failure of meeting the business objectives will trigger the modification of business processes as well as system modelling and application development The SMP checklist manual assessment should take place a minimum of every 6 months Figure 4 shows the SMP checklist manual assessment life cycle Figure 4 SMP checklist manual assessment life cycle 5 CONCLUSION The DBOA has provided a mechanism to improve the communication gap between the software developers and the business management hence the essence of the software will become more strategically based and industry focused The manual assessments on the SMP checklists during the pre and post project phases have enabled organisations to justify how the software can support their SMP The integration of IT to business is to raise the software developers awareness that when business strategies and software applications are linked together to form a single pool of knowledge software development is more likely to support the business strategies hence to achieve the business goals 6 FURTHER WORK The underlying DBOA framework has been designed to offer a complete conceptual framework and lifecycle basis for business application development A prototype business object repository based on hyperlink documents and web launched plug in tools has been developed An implementation of the DBOA through an e commerce project case study is on going At the time of submitting this paper outstanding tasks include The post project assessment of the SMP checklist with the business end users to evaluate the DBOA against the SMP Any identified failures to meet business objectives will trigger the process improvement stage which filters through the object modelling and application design At the moment the SMP checklists are still very generic for any organisations in any industries It is necessary to streamline the SMP checklists by customising them to suit different business sectors The development of an automated tool to link the SMP checklist templates to the ISO9000 Standard Operating Procedure for business process templates and the business process templates filter through the object modelling and application design to eliminate error prompt 7 REFERENCES Baker 96 Baker M Workflow Meets Business Objects

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

  • Structuring Specification of Business Systems with UML
    package behavior It can however be difficult to develop it correctly especially in complex cases The use case interaction diagram is easy to develop but it describes only typical scenarios consisting of use cases in the package Fig 7 represents the UML activity diagram representing the lifecycle of the use case package order management The activities on this activity diagram correspond to the use cases discussed in Figs 4 5 and 6 Please note that the UML metamodel does not define any mapping from states or action states to use case instances Such mapping might be defined by the development process similar to the approach by Martin and Odell in which states of the subsystem indicate candidate classes in the subsystem see reference 5 However other development processes might define the semantics of the use case package lifecycle in a different way For example the purpose of the use case package lifecycle might be to specify the allowable order of subsystem interface operations in the scope of the use case package There is one more significant difference between the use case interaction model and the use case lifecycle their placement in the project repository is different and their relationships to other design artifacts are different The artifact use case interaction model is related to the artifact use case model The artifact use case package lifecycle is related to the artifact use case package which is one level of abstraction higher than the corresponding use case model and use case interaction model Please see Fig 8 and the next section for details Fig 8 Relationship between artifacts in the use case view in the project repository The notation is modified UML For better clarity dependencies were adorned by role ends Pattern of Design Artifacts During the development process software architects designers and developers identify certain information about the software product Examples of such information are the use cases the software architecture the object collaborations and the class descriptions The information can be very abstract such as the vision of the product or very concrete such as the source code In this paper I call such pieces of information about the software product design artifacts We must realize that there is a difference between a design artifact and its representation The design artifact determines the information about the business system and the representation determines how the information is presented Some design artifacts are represented in UML and some are represented by text or by tables For example the class lifecycle can be represented by a UML statechart diagram an activity diagram state transition table or in Backus Naur form The object interactions can be represented by UML sequence diagrams or by UML collaboration diagrams The class responsibility is represented by text A useful specification of a business system is based on precisely defined design artifacts rather than on diagrams This section and the following section discuss a structure of the design artifacts which provides clear tracing of information describing business processes business rules a software architecture and a design of the business system The structure can easily be extended to cover other aspects of the business system such as the team structure and the project planning Business systems can be described at various levels of abstraction and in various views Some examples of levels of abstraction are the organizational level the system level the architectural level and the class level Some examples of views are the logical view the use case view the analysis view the testing view or the use documentation view At each level of abstraction and in each view the software product can be described by four design artifacts static relationships between classifiers dynamic interactions between classifiers classifier responsibilities and classifier lifecycles Each of these artifacts can be represented by UML diagrams or by text The pattern is illustrated in Figs 9 and 10 Please see reference 3 for more information about applications of the pattern to other aspects of software design such as the testing database design user interface and user documentation aspects Fig 9 The pattern of design artifacts for structuring project repositories Fig 10 At each level of abstraction and in each view the software product can be described by four design artifacts UML classifiers are class interface use case node subsystem and component The classifier model specifies static relationships between classifiers The classifier model can be represented by a set of static structure diagrams if classifiers are subsystems classes or interfaces a set of use case diagrams if classifiers are use cases and actors a set of deployment diagrams if classifiers are nodes and a set of component diagrams in their type form if classifiers are components The classifier interaction model specifies interactions between classifiers The classifier interaction model can be represented by interaction diagrams sequence diagrams or collaboration diagrams The UML Notation Guide describes only interaction diagrams in which classifiers are objects it does not describe interaction diagrams in which classifiers are use cases subsystems nodes or components The design artifact called classifier specifies classifier responsibilities roles and static properties of classifier interfaces for example a list of classifier operations with preconditions and postconditions Classifiers can be represented by structured text for example in the form of a CRC card The classifier lifecycle specifies classifier state machine and dynamic properties of classifier interfaces for example the allowable order operations and events The classifier lifecycle can be represented by a statechart diagram an activity diagram and a state transition table An instance of the classifier model can be linked to several instances of the classifier interaction model All of these instances are linked to instances of the classifier An instance of the classifier is linked to an instance of the classifier lifecycle Structuring the Project Repository In well structured design specification the required information about business processes and software products can be easily located and closely related information is linked together The structure should also give an overview about the completeness and consistency between design

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

  • Business Procedures are not Represented Adequately
    services it requests from the business entities 3 Business Logic in Application Architectures 3 1 Club Med Example Orfali OH97 presents as an example a complete travel agency mini application An applet on the client contains the presentation layer and the business logic The server contains the business entity layer and the database access The application is in our terminology a business procedure that consists of one business activity booking of vacations with a club med The activity consists of several subactivities presentation of all club villages and selection of a club selection of a vacation week in the selected club booking the selected week for the desired number of persons displaying the bookings and canceling a booking Each of the subactivities presents a screen of its own for data display and data entry There are two execution sequences to each of which a subset of the subactivities belongs One panel is associated with the application i e the activity in which all subactivity screens are presented by a card layout manager each screen being like a card in a stack of cards only the topmost one being visible One user input handler handles all user events originating from the screens of all different subactivities The handler switches the screens when required and thus switches implicitly from one subactivity to the next The application design does not represent statically and explicitly the one level hierarchy of activities and subactivities nor the conditional sequencing of subactivities nor which screen belongs to which subactivity Though the application code is quite well structured one has to analyze the dynamically control flow in order to get an understanding of subactivities the screens which belong to them and of the business entities each one accesses 3 2 Fowler s Application Logic Tier Fowler F97 recommends to introduce an application logic tier in addition to the presentation tier and domain tier and describes the application logic tier as follows A selection and simplification of the domain model for an application Contains no user interface code but provides a set of facades of the domain tier for the user interface Converts types He proposes to prepare a facade for each presentation The facade has a feature for each element on the corresponding user interface Each presentation thus has a simple interface to the domain model that minimizes any processing for the presentation other than the user interface A facade method is called from a presentation event handler The method may contain a sequence of calls to business entity services for example in order to calculate a result that is to be displayed by the presentation object Such a sequence of requests of business entity services is business logic However it represents only a very small and detailed piece of a business procedure typically only a piece of a business subactivity The application logic tier does neither represent business activities nor subactivities nor the creation of new business objects nor the access to existing ones since this is

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



  •