US20070094641A1 - Product configuration using configuration patterns - Google Patents

Product configuration using configuration patterns Download PDF

Info

Publication number
US20070094641A1
US20070094641A1 US11/552,756 US55275606A US2007094641A1 US 20070094641 A1 US20070094641 A1 US 20070094641A1 US 55275606 A US55275606 A US 55275606A US 2007094641 A1 US2007094641 A1 US 2007094641A1
Authority
US
United States
Prior art keywords
configuration
pattern
patterns
product
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/552,756
Inventor
Timothy Darr
Raymond Beaumont
Nirad Sharma
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37807291&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20070094641(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Individual filed Critical Individual
Priority to US11/552,756 priority Critical patent/US20070094641A1/en
Publication of US20070094641A1 publication Critical patent/US20070094641A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/10Requirements analysis; Specification techniques

Definitions

  • the present invention relates generally to the field of computer-based product configuration.
  • Configuring a product refers to the process of selecting, constructing, and connecting components to satisfy a particular need or request. Configuring a product has been described, for example, in U.S. Pat. No. 5,515,524 entitled “Method and Apparatus for Configuring Systems”, inventors J. Lynch and D. Franke. If a product is based on a limited number of components, the process of configuring the product can be relatively straightforward. “Component” and “part” are often used interchangeably to denote the elements of a product.
  • a complex product is a telecommunications switching system.
  • the available configuration alternatives of a telecommunications switching system are numerous and varied, including alternatives available when choosing the equipment racks, shelves, communications boards, power supply, consoles, cables, and software.
  • Configuring a product generally requires compatibility between a selected component and other components in the configured product.
  • a power supply must generally be sufficient to supply power to all of the components of the product receiving power from the power supply.
  • An equipment shelf has only a certain number slots to handle all of the boards installed in that shelf.
  • Configuration modeling software for automating the configuration process has been developed.
  • Configuration modeling software is particularly applicable to constraint-based configuration systems.
  • a constraint-based system places constraints on the use of a component in a configuration. For example, a hard disk drive cannot be added to the configuration unless a compatible storage device controller is available for use by a requested storage device. The requirement of a controller is a “constraint” on the hard disk drive.
  • configuration modeling software can address configurations for complex products
  • the configuration modeling software itself is generally very complex and requires a high level of skill and effort to maintain and to create new product configurations.
  • even simple modifications to the configuration modeling software may require significant time and effort to implement, leading to significant cost and expense.
  • configuration modeling The activity of creating a representation of some product to be configured by a configuration engine is generally called “configuration modeling”, or more simply “modeling.” This activity includes the following tasks:
  • Tasks 1 - 2 require deep domain knowledge of the type typically held by product managers or engineers (the “product expert”) in the company that manufactures or sells the product.
  • Tasks 3 - 5 require advanced programming skill and a high-degree of domain knowledge, typically held by programmers (the “modeler”).
  • configuration patterns provide solutions to configuration problems that repetitively occurs for some product or family of products.
  • Configuration patterns can be developed for industry and product specific configuration problems such as the difficult problems associated with configuring telecommunications optical switches.
  • configuration patterns are organized into a hierarchy to achieve programming efficiency. Multiple hierarchies could be created and applied by product configuration elements, such as model classes and components. The pattern hierarchy can be applied at any level of a product hierarchy.
  • a configuration model for use with a product configuration software system includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • a product configuration system in another embodiment, includes a configuration engine and a product model accessible by the configuration engine.
  • the product model includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • a software distribution method in another embodiment, includes distributing a software system to a first enterprise, distributing the software system to a second enterprise.
  • the software system includes a configuration engine and a product model.
  • the product model includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • a configuration system in another embodiment, includes a model for use with a digital computing device, the model configured to define a configuration model having information about telecommunication industry components and logic available for configuring a product in a telecommunications industry system, the model including configuration patterns.
  • the configuration system also includes a configuration engine having access to the model, the configuration engine configured to select a plurality of the telecommunication industry components of the configuration model for inclusion in the telecommunication industry system in response to configuration requests.
  • a configuration apparatus in another embodiment, includes a model for use with a digital computing device, the model configured to define a configuration model having information about telecommunication industry components and logic available for configuring a product, the model including configuration patterns.
  • the configuration apparatus further includes a configuration engine having access to the model, the configuration engine configured to use the model to generate a product configuration.
  • a method of configuring a product using at least one configuration pattern of a product model that includes components and logic used to configure a product and structural relationships between instances of the components in the product model, the method comprising creating a product configuration using the product model comprising receiving attributes to respectively control behavior of each configuration pattern, wherein each configuration pattern includes reusable configuration logic for implementing repeatable configuration functions, creating one or more instances of components in the model that are candidates for configuration in response to configuration requests, for each of the component instances, determining whether to apply any configuration pattern during configuration of the component instance, and evaluating the logic of any configuration patterns to be applied to a configuration assistance in accordance with the attributes received to control the configuration patterns.
  • a user interface for obtaining data useful for controlling behavior of configuration patterns of a configuration model, the user interface including a display of information to prompt a user to supply data for use by a configuration system in controlling the behavior of configuration patterns in a configuration model.
  • FIG. 1 illustrates general representation of a configuration system.
  • FIG. 2 illustrates one embodiment of a product hierarchy model.
  • FIG. 3 illustrates one embodiment of a pattern hierarchy.
  • FIG. 4 illustrates one embodiment of an interface for configuration patterns.
  • FIG. 5 illustrates one embodiment of an interface for a configuration pattern filter class.
  • FIG. 6 illustrates one embodiment of an interface for configuration pattern initializer class.
  • FIG. 7 illustrates the activity of a configuration pattern on a component.
  • FIG. 8 illustrates one embodiment of a pattern used for configuring an optical interface circuit board.
  • FIGS. 9A, 9B , and 9 C illustrate one embodiment of consecutive computer interface displays presented to a product expert for entering data associated with an optical tributary board.
  • FIG. 10 illustrates a general flow diagram of a method of creating a product base.
  • FIG. 11 illustrates a general block diagram that illustrates a software distribution method.
  • FIG. 12 represents a block diagram illustrating a network environment in which the configuration system 100 and modeling may be practiced.
  • FIG. 13 illustrates a general purpose computer with which configuration system 100 and modeling processes can be implemented.
  • Configuration systems particularly constraint-based configuration systems utilize models of products to generate configurations.
  • product is used generically to refer to tangible products as well as intangible products, such as services.
  • Configuration systems as described, for example, in U.S. Pat. No. 5,515,524 entitled “Method and Apparatus for Configuring Systems”, inventors J. Lynch and D. Franke (referred to as the “Lynch/Franke Patent” and hereby incorporated by reference in its entirety), have been successfully developed and used to solve the problem associated with the enormous number of combinations to be considered when searching through the space of configurable solutions.
  • configuration patterns 102 have been introduced into the configuration system 100 having an architecture that, in one embodiment, includes configuration patterns 102 as part of product model 104 . It has been observed that common modeling solutions to common problems abound in configuration problems. In many cases, common modeling problems can be solved efficiently using configuration patterns (also referred to as “patterns” for conciseness).
  • a configuration pattern 102 is a solution to a configuration problem that repetitively occurs for some product or family of products (collectively a “product”).
  • the configuration pattern 102 is a parameterized or otherwise easily extensible solution to that problem, such that the solution is reusable by modifying the parameters of the pattern or extending the pattern in well-defined ways. For example, slotting a card with 1+1 protection, i.e.
  • the configuration engine 106 can use the model 104 and specifically the slot-card-with-1+1-protection configuration pattern of patterns 102 to determine if the request can be accommodated and a product configuration output 110 generated that slots the requested card plus a protection card.
  • the configuration engine 106 and model 104 describe the components and logic for configuring a complex product that satisfies a particular set of needs or request inputs.
  • the Lynch/Franke Patent describes an example configuration engine 106 and its interaction with a general model.
  • the behavior of the model with configuration patterns when used by a configuration engine is determined in part by data provided by the product expert.
  • the data provides information that specifies values of attributes that influence the configuration solutions determined by a configuration engine when using the model.
  • pattern-based modeling allows the modeling process to be separated into two aspects: (1) development of the configuration product model based on a generalized modeling language (developed and maintained by modelers skilled in the particular modeling language) and (2) provision of product data that customizes a particular model for a particular product (maintained by product experts not necessarily skilled in the particular modeling language).
  • the embodiment in aspect (1) above is a pre-packaged configuration model, which provides commonly-encountered configuration tasks and accepts a variety of data provided by the product expert.
  • some embodiments of the invention provide tools such as user interface 901 to a product expert that allow the product expert to customize the model through data entry.
  • Embodiments of pattern-based modeling provide, for example, the following benefits:
  • a configuration pattern can be reused to solve a variety of problems by changing the parameters of the pattern; an application of a configuration pattern is the parameterization of the pattern for a specific problem.
  • applications of the pattern can be maintained as data.
  • the data that drives the configuration pattern can be represented in XML or any other structured data format.
  • Implementation of the pattern is done in any configuration engine modeling language with sufficient robustness and expressiveness to facilitate the desired model characteristics.
  • Such modeling languages include JavaTM from California based Sun Microsystems and CML, the configuration modeling language of Austin, Tex. based Trilogy Software, Inc.TM.
  • patterns are essentially responsible for providing configuration logic to the configuration engine, whether it be slotting a card, configuring an amplifier card for an optical interface card, or configuring the high-speed interface lines and their supporting cards for an optical add-drop multiplexer.
  • the configuration engine 106 applies the appropriate patterns 102 to components (not shown) in the configuration model, i.e. when a component is instantiated (i.e. created).
  • the logic associated with the patterns 102 will be evaluated by the configuration engine 106 in the context of that component to perform the requested configuration task.
  • Which pattern or patterns are appropriate for application is described in more detail below with reference to the applied_patterns 228 attribute.
  • the “#” associated with an attribute name indicates that the attribute in the particular depicted embodiment is a protected attribute that can only be used by selected classes, such as descendent classes.
  • FIG. 2 illustrates an example product hierarchy model.
  • the Component_Class 202 is the most general class or “thing” in the model; all other classes and components descend from the Component_Class 202 . Each descendent class can inherit data and logic associated with higher-level classes through which a class descends.
  • the example product modeling hierarchy 200 contains three base classes, Composite_Base_Class 204 , Connector_Base_Class 206 , and Container_Base_Class 208 .
  • the Component Class 202 , Composite_Base_Class 204 and Part_Class_ 1 contain product data such as part-numbers, descriptions, and the type and number of ports provided by an optical interface card.
  • Product modeling hierarchy 200 is further organized to contain derived classes such as Part_Class_ 1 210 , Part_Class_ 2 212 , Part_Class_ 3 214 , and Part_Class_ 4 216 .
  • Part_Class_ 5 descends directly from Component_Class 202 .
  • Each Part_Class_X class represents broad component categories such as optical interface cards. Although only one generation of derived classes is shown, multiple generations of derived classes can descend from base classes.
  • the Part_Classes terminate with component types, for example, Component_ 1 220 , Component_ 2 222 , Component_ 3 224 , Component_ 4 226 , Component_ 5 236 .
  • Component_ 6 238 descends directly from Component Class 202 .
  • Component types are generically referred to herein as “components”.
  • Components_Y include actual components that can be instantiated and configured such as “OC-3 optical interface card with SC connectors”.
  • the Component_Class 202 also contains data related to the configuration patterns 218 that it can apply.
  • the attribute “applied_patterns 228 ” specifies which configuration patterns 218 will be applied.
  • attributes “required_patterns 232 ” and “optional_patterns 230 ” define the required patterns and optional patterns, respectively.
  • the attribute applied_patterns 228 is the union of the required_patterns 232 and optional_patterns 230 , filtered to remove exclusive patterns and sorted by pattern application priority, which provides an ordering on the patterns.
  • Pattern application ordering can be indicated in any manner using any techniques including numerical techniques, non-numeric partial orders, represented by directed graph structures, and other reference techniques.
  • ConfigurationPatterns 218 descend from other members of the product modeling hierarchy 200 . By descending from the highest node of product modeling hierarchy 200 , all classes and components of product modeling hierarchy 200 are able to apply ConfigurationPatterns 218 through inheritance.
  • those configuration patterns 218 specified in required_patterns 232 are always applied to the class (or component) the attribute is set on.
  • Configuration patterns 218 specified in optional_patterns 230 can be, but do not have to be applied. In this embodiment, only the applied configuration patterns 218 are evaluated (applied) during creation or instantiation of the component.
  • product managers enter data on individual components and select those patterns that are applicable to the selected components using, for example, the data entry displays discussed in conjunction with FIGS. 9A, 9B , and 9 C.
  • an optical interface card might have the following patterns selected for application to the components in the product hierarchy model 200 associated with an optical interface card:
  • all configuration patterns that are relevant for a certain configuration model are defined in a pattern hierarchy 300 illustrated in FIG. 3 .
  • a pattern hierarchy is used, for example, to achieve programming efficiency by allowing patterns to inherit common functions and attributes while allowing customization in descendent patterns through addition of functionality and attributes. Descendent patterns may also override all or a portion of inherited functionality and attributes.
  • the pattern hierarchy 300 contains a general pattern class referred to as ConfigurationPattern 302 and descendent pattern classes 304 that descend from ConfigurationPattern 302 and inherit ancestor class attributes.
  • Example descendent pattern classes 304 are RequiresResourceProvider 306 and ConfigureSupportingCard 308 , which descends directly from ConfigurationPattern 302 , and ConfigureInterfaceCard 310 , which descend directly from RequiresResourceProvider 306 .
  • the ConfigureOpticalInterfaceCard 312 and ConfigureElectricalInterfaceCard 314 patterns descend directly from the ConfigureInterfaceCard 310 pattern.
  • the descendent pattern classes 304 are described above.
  • a pattern can be defined for (and applied to) disjoint hierarchies within the product modeling hierarchy 200 , i.e. to any class or component in the product modeling hierarchy 200 .
  • ConfigurationPatterns 302 is applied to Component_Class 322 . If the ConfigurationPatterns 302 , as defined in the product model 104 , completes successfully, i.e. the configuration is valid, the instance of the ConfigurationPatterns 302 is deleted to free up memory for future configuration evaluations. In one embodiment, a transient property is established to delete ConfigurationPattern 302 . This property can be inherited through any descendent of ConfigurationPatterns 302 .
  • the optical application pattern hierarchy 300 example provides an example of how a component instance applies patterns. Patterns are applied to components such that the logic associated with the pattern is used by the component to perform some configuration task. Access to the instance for which the pattern is being evaluated, or the component that is using the pattern, is given by the _pattern_context_CI 318 attribute, which is an inverse attribute of the attribute _pattern_CI 320 , which points to the pattern being evaluated.
  • the component applying the pattern depicted in FIG. 3 is _pattern context_Cl:Component_Class 322 .
  • ConfigurationPatterns 302 could also be applied, for example, to any descendent of Component_Class 202 , such as Composite_Base_Class 204 , Connector_Base_Class 206 , Container_Base_Class 208 , Part_Class_X, or Component_Y.
  • a pattern preferably does not contain any product data as part of its definition so as to allow patterns to be applied freely without being constrained by specific product data. All product and domain specific data is preferably defined in the product hierarchy model 200 , as described above.
  • the attribute pattern_application_priority_F 324 which is in one embodiment a floating point variable, specifies an ordering over the patterns that are applied to a component to control the dependencies between patterns. Patterns 218 with higher values are applied first in one embodiment. For example, the SlotCard pattern must be evaluated before the ConfigureProtectionCard pattern, since the ConfigureProtectionCard pattern requires that the card that requires protection is slotted.
  • Patterns 218 can be mutually exclusive because certain components in the product hierarchy model 200 may not have the same pattern behavior (configuration logic) of two different patterns at the same time. Therefore, for each pattern, the attribute exclusive_patterns_mCL 326 specifies which patterns are mutually exclusive with the pattern.
  • Patterns can also be used to do global and contextual filtering and initializations. This is logic that can be applied to all instances and candidate components for instantiation or a subset of instances and candidate components for instantiation that satisfy some context in the product.
  • the global and contextual filtering could include effectivity filtering for determining when a particular component candidate for instantiation can be configured and initialization of component instance attributes after instantiation. Filters provide a way to customize the behavior of a pattern in pre-defined ways by adding filters to a multi-valued list that is applied by all patterns. Similarly, initializers can provide a way to initialize attributes on instances created by or used by all patterns.
  • the PatternFilter 328 and PatternInitializer 330 classes are provided for this purpose. PatternFilter 328 and PatternInitializer 330 classes implement the IPatternFilter and IPatternInitializer interfaces, respectively, to perform the predetermined filtering and initialization.
  • the pattern_filters_mCL attribute 332 contains a list of filters to be applied by the pattern for global filtering and the pattern_initializers_mCL 334 attribute contains a list of initializers to be applied by the pattern for global initializations.
  • the attributes pattern_filters_mCL attribute 332 and pattern_initializers_mCL 334 should only be used for global and contextual filtering and initialization with pattern specific filtering and initialization being performed via interfaces specific to the pattern. More details on filtering and initialization are provided below.
  • the attribute applied_patterns 228 is evaluated by configuration engine 106 (i.e. pattern instances will be created) for all components, according to the following rules:
  • an instance of a configuration pattern is a transient object. It will be instantiated, then evaluated, and upon completion it will be deleted to free available memory space.
  • the attribute_pattern_context_CI 320 will be set to keep track of the instance for which this pattern is being evaluated, and the attribute _pattern_CI 318 will be set to the pattern that is being evaluated.
  • a configuration engine 106 utilizes instances of components is a matter of design choice but can be preferable for controlling memory usage. Additionally, by creating multiple instances of a component, each instance of the component can be assigned different attribute values.
  • configuration engine 106 performs the following:
  • filters and initializers can be of two forms:
  • the ConfigurationPattern 302 class uses the interface IConfigurationPattern 400 to filter and initialize component instances or candidate components for instantiation.
  • the IConfigurationPattern 400 contains two functions:
  • the PatternFilter class 328 uses the interface IPatternFilter 500 to implement filtering logic.
  • Each sub-class of the PatternFilter class 328 overrides the functions in the IPatterFilter interface to implement the logic specific to that filter.
  • IPatternFilter 500 contains one function:
  • the PatternInitializer class 600 uses the interface IPatternInitializer ( FIG. 3 ) to implement the initialization logic. Each sub-class of the PatternInitializer class 600 overrides the functions in the IPatternInitializer interface to implement the logic specific to that initializer.
  • PatternInitializer class 600 contains one function:
  • FIG. 7 presents a summary of the descriptions above by illustrating the activity of a pattern on a component.
  • Each component has a list of patterns that it needs to apply, stored in the attribute applied_patterns 702 .
  • the diagram in FIG. 7 illustrates the application of a single pattern in this list; this activity is repeated for each element of the list.
  • the component instance applying the patterns is denoted _pattern_context_CI 704 .
  • the pattern illustrated in this diagram simply instantiates another component, _dependent_instance_CI: Component 708 .
  • An example pattern that demonstrates the activities depicted in FIG. 7 is a pattern that configures an amplification card for an optical interface card, based on the fiber type and span of a transmission line. It will be apparent to those of ordinary skill in the art that more complicated patterns can be created using the principles of pattern application depicted in FIG. 7 and described below.
  • the configuration engine 106 evaluates the patterns stored in the attribute applied_patterns 228 ( FIG. 2 ).
  • the pattern, Configuration_Pattern 716 is instantiated (message instantiate( ) 703 from the _pattern_context_CI 704 to Configuration_Pattern 716 ), and then applies pattern logic contained in Configuration_Pattern 716 to _pattern_context_CI 704 (message applyPatternLogic( ) from the pattern to the context).
  • the logic involved in this Configuration_Pattern 716 involves instantiating _dependent_instance_CI: Component 708 using the instantiate( ) message 709 .
  • configuration engine 106 establishes dependency between _dependent_instance_CI: Component 708 and _pattern_context_CI 704 via the establishDependency( ) message. This dependence can be used so that if any dependent instances were to be deleted, the _pattern_context_CI component 704 would be deleted as well, as described previously.
  • the pattern logic of Configuration_Pattern 716 is complete (the return( ) message 713 ) and Configuration_Pattern 716 is destroyed (the destroy( ) message 714 ).
  • pattern instances are transient objects that live only as long as necessary to achieve the task they are designed to perform.
  • Pattern-based configuration the primary task of the modeler becomes studying the product to be modeled and identifying the patterns that are necessary for configuring the product. Patterns are identified by recognizing generally repetitive tasks that occur over and over again across product families. This introduces a level of abstraction that was not previously available.
  • a list of broad patterns for a particular domain is usually easily identifiable with experience in configuring products in that domain. The details and specifics of the patterns can be discovered with the help of product expert(s).
  • the AmplifyOpticalSignal pattern simplifies the task of gathering information. Patterns help to focus attention on what information needs to be collected to accurately configure the product. For example, the AmplifyOpticalSignal pattern requires the following information:
  • a simple data sheet can be constructed to help gather information for patterns.
  • a sample data sheet for tributary cards is shown in FIG. 9 .
  • This data sheet can be used by a product expert, or by a modeler working with a product expert, to gather the attributes for a pattern. It can also be used to identify the gaps in the logic of existing patterns.
  • Pattern identification requires a moderate level of product knowledge, and the ability to implement configuration logic, either extensions of existing patterns, or new patterns, using the modeling language of a configuration engine.
  • FIG. 8 illustrates the ConfigureOpticalInterfaceCard pattern 802 .
  • the ConfigureOpticalInterfaceCard pattern 802 is used to instantiate one or more optical interface cards 801 , based on the type of optical interface (OC-3, OC-12, OC-48, etc) required.
  • the ConfigureOpticalInterfaceCard pattern 802 could be used to, for example, satisfy the requirements of an optical tributary or a high-speed interface.
  • optical interface card 801 The characteristics of the required optical interface card 801 are specified by the attributes in the OpticalInterfaceCardRequirement 804 component, as shown in the diagram. Specifically, optical interface cards may be described by the following:
  • the IConfigureOpticalInterfaceCard interface contains functions that can be overridden by patterns that specialize this pattern. Patterns generally include interfaces to make extending the patterns easier.
  • An example of a pattern that would override the ConfigureOpticalInterfaceCard pattern 802 is the ConfigureOpticalTributary pattern, which includes the option of whether or not the card needs to be protected. Creating the ConfigureOpticalTributary pattern is simply a matter of overriding a single function to initialize attributes on the instantiated interface card, indicating whether or not protection is needed.
  • FIG. 9 presents an example computer interface that could be presented to a product expert for entering data associated with an optical tributary card.
  • user interface 901 the data entered by the product expert would be used to populate the product model 104 with data for use by configuration engine 106 during configuration of a product.
  • the configuration engine 106 uses a compiled version of product model 104 , referred to as a product base 1002 .
  • Different configuration engines are designed to use configuration logic and data information in different formats.
  • configuration engine 106 such as the configuration engine described in the Lynch/Franke Patent
  • the compilation operation 1004 functions to compile the product data 1006 , configuration patterns 102 , product modeling hierarchy 200 of product model 104 into product base 1002 , which is directly useable by configuration engine 106 .
  • the product base 1002 becomes the product model utilized by configuration engine 106 to generate a product configuration.
  • product model 104 may be created in a state that is directly useable by configuration engine 106 .
  • the configuration system 100 includes the configuration engine 116 and the product model 104 .
  • the configuration system 100 is copied and distributed to a plurality of different enterprises, such as first enterprise 1102 , second enterprise 1104 , and Nth enterprise 1 106 .
  • the configuration system 100 may be distributed to several different enterprises.
  • each of the enterprises may use the system 200 to build product specific and company specific configuration models for use in software enabled configurations of various selected products.
  • Each enterprise by adding specific product data, can customize the configuration system for such enterprise's specific needs.
  • the configuration system 100 may be embedded into an article of manufacture, such as a tape or other software storage device or tangible medium.
  • FIG. 12 is a block diagram illustrating a network environment in which the configuration system 100 and modeling may be practiced.
  • Network 1202 e.g. a private wide area network (WAN) or the Internet
  • WAN wide area network
  • server computer systems 1204 1 )-(N) that are accessible by client computer systems 1206 ( 1 )-(N), where N is the number of server computer systems connected to the network.
  • Communication between client computer systems 1206 ( 1 )-(N) and server computer systems 1204 ( 1 )-(N) typically occurs over a network, such as a public switched telephone network over asynchronous digital subscriber line (ADSL) telephone lines or high-bandwidth trunks, for example communications channels providing T1 or OC 3service.
  • ADSL synchronous digital subscriber line
  • Client computer systems 1206 ( 1 )-(N) typically access server computer systems 1204 ( 1 )-(N) through a service provider, e.g., an Internet service provider such as America On-LineTM, and the like by executing application specific software, commonly referred to as a browser, on one of client computer systems 1206 ( 1 )-(N).
  • a service provider e.g., an Internet service provider such as America On-LineTM, and the like
  • application specific software commonly referred to as a browser
  • Client computer systems 1206 ( 1 )-(N) and/or server computer systems 1204 ( 1 )-(N) may be, for example, computer systems of any appropriate design, including a mainframe, a mini-computer, a personal computer system, or a wireless, mobile computing device. These computer systems are typically information handling systems, which are designed to provide computing power to one or more users, either locally or remotely. Such a computer system may also include one or a plurality of input/output (“I/O”) devices coupled to the system processor to perform specialized functions. Mass storage devices such as hard disks, CD-ROM drives and magneto-optical drives may also be provided, either as an integrated or peripheral device.
  • I/O input/output
  • Mass storage devices such as hard disks, CD-ROM drives and magneto-optical drives may also be provided, either as an integrated or peripheral device.
  • FIG. 13 One such example computer system is shown in detail in FIG. 13 .
  • Embodiments of the configuration system 100 and modeling processes can be implemented on a computer system such as a general-purpose computer 1300 illustrated in FIG. 13 .
  • Input user device(s) 1310 such as a keyboard and/or mouse, are coupled to a bi-directional system bus 1318 .
  • the input user device(s) 1310 are for introducing user input to the computer system and communicating that user input to processor 1313 .
  • the computer system of FIG. 13 also includes a video memory 1314 , main memory 1315 and mass storage 1309 , all coupled to bi-directional system bus 1318 along with input user device(s) 1310 and processor 1313 .
  • the mass storage 1309 may include both fixed and removable media, such as other available mass storage technology.
  • Bus 1318 may contain, for example, 32 address lines for addressing video memory 1314 or main memory 1315 .
  • the system bus 1318 also includes, for example, an n-bit DATA bus for transferring DATA between and among the components, such as CPU 1309 , main memory 1315 , video memory 1314 and mass storage 1309 , where “n” is, for example, 32 or 64.
  • multiplex DATA/address lines may be used instead of separate DATA and address lines.
  • I/O device(s) 1319 may provide connections to peripheral devices, such as a printer, and may also provide a direct connection to a remote server computer systems via a telephone link or to the Internet via an internet service provider (ISP). I/O device(s) 1319 may also include a network interface device to provide a direct connection to a remote server computer systems via a direct network link to the Internet via a POP (point of presence). Such connection may be made using, for example, wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like. Examples of I/O devices include modems, sound and video devices, and specialized communication devices such as the aforementioned network interface.
  • ISP internet service provider
  • Computer programs and data are generally stored as instructions and data in mass storage 1309 until loaded into main memory 1315 for execution. Computer programs may also be in the form of electronic signals modulated in accordance with the computer program and data communication technology when transferred via a network.
  • the method and functions relating to configuration system 100 and modeling processes may be implemented in a computer program alone or in conjunction with hardware implementations.
  • context subsystem data structures can be implemented in CPU 1300 and utilized by CPU 1300 or by other data processing systems that have access to the data structures.
  • the processor 1313 in one embodiment, is a 32-bit microprocessor manufactured by Motorola, such as the 680100 processor or microprocessor manufactured by Intel, such as the 801086, or Pentium processor. However, any other suitable single or multiple microprocessors or microcomputers may be utilized.
  • Main memory 1315 is comprised of dynamic random access memory (DRAM).
  • Video memory 1314 is a dual-ported video random access memory. One port of the video memory 1314 is coupled to video amplifier 1316 .
  • the video amplifier 1316 is used to drive the display 1317 .
  • Video amplifier 1316 is well known in the art and may be implemented by any suitable means. This circuitry converts pixel DATA stored in video memory 1314 to a raster signal suitable for use by display 1317 .
  • Display 1317 is a type of monitor suitable for displaying graphic images.
  • the configuration system 100 and modeling processes may be implemented in any type of computer system or programming or processing environment. It is contemplated that the configuration system 100 and modeling processes might be run on a stand-alone computer system, such as the one described above. The configuration system 100 and modeling processes might also be run from a server computer systems system that can be accessed by a plurality of client computer systems interconnected over an intranet network. Finally, the configuration system 100 and modeling processes may be run from a server computer systems that is accessible to clients over the Internet.

Abstract

In a particular embodiment, configuration patterns are used to provide solutions to configuration problems that repetitively occur. Use of configuration patterns in connection with a configuration model has many benefits. A configuration pattern is a parameterized or otherwise easily extensible solution to that problem, such that the solution is reusable by modifying the parameters of the pattern or extending the pattern in pre-defined ways. Configuration patterns are inherently data-driven and provide improved maintenance for data and logic as well as reduced programming effort. Configuration patterns can be reused within and across different product families and can be specialized from other patterns. Thus, the use of configuration patterns facilitates reduced maintenance cost and reduced programming effort for product configuration data and logic systems.

Description

    CROSS-REFERENCE TO RELATED APPLICATION(S)
  • This application claims the benefit of U.S. Provisional Application No. 60/343,670, filed Dec. 28, 2001 and entitled “Product Configuration Using Configuration Patterns”.
  • This application claims the benefit of U.S. Provisional Application No. 60/343,666, filed Dec. 28, 2001 and entitled “Telecommunications Configuration Model for Product Configuration”.
  • This application relates to “Telecommunications Configuration Model for Product Configuration”, application number______(Attorney Docket No. 027-0008), with common assignee and filed on Feb. 28, 2002.
  • BACKGROUND Field of the Invention
  • The present invention relates generally to the field of computer-based product configuration.
  • Background Description
  • Configuring a product refers to the process of selecting, constructing, and connecting components to satisfy a particular need or request. Configuring a product has been described, for example, in U.S. Pat. No. 5,515,524 entitled “Method and Apparatus for Configuring Systems”, inventors J. Lynch and D. Franke. If a product is based on a limited number of components, the process of configuring the product can be relatively straightforward. “Component” and “part” are often used interchangeably to denote the elements of a product.
  • As product specifications become more customized and varied, configuration alternatives increase and the task of configuring a product becomes more complex. An example of a complex product is a telecommunications switching system. The available configuration alternatives of a telecommunications switching system are numerous and varied, including alternatives available when choosing the equipment racks, shelves, communications boards, power supply, consoles, cables, and software.
  • Configuring a product generally requires compatibility between a selected component and other components in the configured product. For example, a power supply must generally be sufficient to supply power to all of the components of the product receiving power from the power supply. An equipment shelf has only a certain number slots to handle all of the boards installed in that shelf.
  • To address the problem of configuring complex products, configuration modeling software for automating the configuration process has been developed. Configuration modeling software is particularly applicable to constraint-based configuration systems. In general terms, a constraint-based system places constraints on the use of a component in a configuration. For example, a hard disk drive cannot be added to the configuration unless a compatible storage device controller is available for use by a requested storage device. The requirement of a controller is a “constraint” on the hard disk drive.
  • While the configuration modeling software can address configurations for complex products, the configuration modeling software itself is generally very complex and requires a high level of skill and effort to maintain and to create new product configurations. In addition, even simple modifications to the configuration modeling software may require significant time and effort to implement, leading to significant cost and expense.
  • Thus, creating systems for configuration of complex products such as telecommunications systems is a complex task for the following reasons:
    • 1. The problem itself is difficult given the enormous number of combinations to be considered when searching through the space of configurable solutions; and
    • 2. Creating a representation of the product (classes, components and configuration logic) that is easy to maintain and extend is very difficult, often requiring advanced programming skill and deep domain knowledge.
  • The activity of creating a representation of some product to be configured by a configuration engine is generally called “configuration modeling”, or more simply “modeling.” This activity includes the following tasks:
    • 1. Identifying the components that make up the product being configured, and representing them in the modeling language. These are physical things such as circuit boards, cables, shelves, racks, etc.
    • 2. Identifying the logic required to configure the components. Note: “logic” refers to relationships between components which can be, for example, functional or physical such as how the components are connected, e.g. a circuit board is slotted in a particular slot.
    • 3. Creating abstractions of the components to allow the configuration engine to solve a configuration problem more efficiently and take advantage of inheritance, encapsulation (data hiding) and other object-oriented features provided by most modem programming languages.
    • 4. Implementing the often-complex configuration conditions in the representation or modeling language of the configuration engine. Configuration conditions can be expressed in a variety of ways including as rules and constraints.
    • 5. Creating a model that is both maintainable and extensible. It should be easy to add new parts and logic, without invalidating the existing model.
  • Tasks 1-2 require deep domain knowledge of the type typically held by product managers or engineers (the “product expert”) in the company that manufactures or sells the product. Tasks 3-5 require advanced programming skill and a high-degree of domain knowledge, typically held by programmers (the “modeler”).
  • One of the difficulties and significant source of expense in modeling a product results from the fact that it is rare that one individual possesses the knowledge required for tasks 1-5.
  • SUMMARY
  • In one embodiment of the present invention, configuration patterns provide solutions to configuration problems that repetitively occurs for some product or family of products. Configuration patterns can be developed for industry and product specific configuration problems such as the difficult problems associated with configuring telecommunications optical switches. In one embodiment, configuration patterns are organized into a hierarchy to achieve programming efficiency. Multiple hierarchies could be created and applied by product configuration elements, such as model classes and components. The pattern hierarchy can be applied at any level of a product hierarchy.
  • In one embodiment, a configuration model for use with a product configuration software system includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • In another embodiment, a product configuration system includes a configuration engine and a product model accessible by the configuration engine. The product model includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • In another embodiment, a software distribution method includes distributing a software system to a first enterprise, distributing the software system to a second enterprise. The software system includes a configuration engine and a product model. The product model includes configuration patterns having configuration logic for performing tasks related to a configuration of a product.
  • In another embodiment a configuration system includes a model for use with a digital computing device, the model configured to define a configuration model having information about telecommunication industry components and logic available for configuring a product in a telecommunications industry system, the model including configuration patterns. The configuration system also includes a configuration engine having access to the model, the configuration engine configured to select a plurality of the telecommunication industry components of the configuration model for inclusion in the telecommunication industry system in response to configuration requests.
  • In another embodiment, a configuration apparatus includes a model for use with a digital computing device, the model configured to define a configuration model having information about telecommunication industry components and logic available for configuring a product, the model including configuration patterns. The configuration apparatus further includes a configuration engine having access to the model, the configuration engine configured to use the model to generate a product configuration.
  • In a further embodiment, a method of configuring a product using at least one configuration pattern of a product model that includes components and logic used to configure a product and structural relationships between instances of the components in the product model, the method comprising creating a product configuration using the product model comprising receiving attributes to respectively control behavior of each configuration pattern, wherein each configuration pattern includes reusable configuration logic for implementing repeatable configuration functions, creating one or more instances of components in the model that are candidates for configuration in response to configuration requests, for each of the component instances, determining whether to apply any configuration pattern during configuration of the component instance, and evaluating the logic of any configuration patterns to be applied to a configuration assistance in accordance with the attributes received to control the configuration patterns.
  • In another embodiment, a user interface for obtaining data useful for controlling behavior of configuration patterns of a configuration model, the user interface including a display of information to prompt a user to supply data for use by a configuration system in controlling the behavior of configuration patterns in a configuration model.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates general representation of a configuration system.
  • FIG. 2 illustrates one embodiment of a product hierarchy model.
  • FIG. 3 illustrates one embodiment of a pattern hierarchy.
  • FIG. 4 illustrates one embodiment of an interface for configuration patterns.
  • FIG. 5 illustrates one embodiment of an interface for a configuration pattern filter class.
  • FIG. 6 illustrates one embodiment of an interface for configuration pattern initializer class.
  • FIG. 7 illustrates the activity of a configuration pattern on a component.
  • FIG. 8 illustrates one embodiment of a pattern used for configuring an optical interface circuit board.
  • FIGS. 9A, 9B, and 9C illustrate one embodiment of consecutive computer interface displays presented to a product expert for entering data associated with an optical tributary board.
  • FIG. 10 illustrates a general flow diagram of a method of creating a product base.
  • FIG. 11 illustrates a general block diagram that illustrates a software distribution method.
  • FIG. 12 represents a block diagram illustrating a network environment in which the configuration system 100 and modeling may be practiced.
  • FIG. 13 illustrates a general purpose computer with which configuration system 100 and modeling processes can be implemented.
  • The use of the same reference symbols in different drawings indicates similar or identical items.
  • DESCRIPTION OF EMBODIMENTS OF THE INVENTION
  • Configuration systems, particularly constraint-based configuration systems utilize models of products to generate configurations. Note: The term “product” is used generically to refer to tangible products as well as intangible products, such as services. The increasing number and complexity of product configuration options and the increasing complexity of products in general has resulted in a significant increase in the complexity of product configuration models. Configuration systems, as described, for example, in U.S. Pat. No. 5,515,524 entitled “Method and Apparatus for Configuring Systems”, inventors J. Lynch and D. Franke (referred to as the “Lynch/Franke Patent” and hereby incorporated by reference in its entirety), have been successfully developed and used to solve the problem associated with the enormous number of combinations to be considered when searching through the space of configurable solutions.
  • However, the modeling process for complex products poses a difficult problem associated with creating a representation of the product (e.g. classes, components, and configuration logic) that is easy to maintain and extend. Conventional technology has struggled with the difficulty and expense of solving this problem with the solution often requiring advanced programming skill and deep domain knowledge throughout the modeling development and maintenance process. Thus, the need has arisen for computer-based assistance with the configuration modeling process. To address this problem, configuration patterns have been developed and are, for example, incorporated as part of a configuration product model.
  • Referring to FIG. 1, configuration patterns 102 have been introduced into the configuration system 100 having an architecture that, in one embodiment, includes configuration patterns 102 as part of product model 104. It has been observed that common modeling solutions to common problems abound in configuration problems. In many cases, common modeling problems can be solved efficiently using configuration patterns (also referred to as “patterns” for conciseness). In one embodiment, a configuration pattern 102 is a solution to a configuration problem that repetitively occurs for some product or family of products (collectively a “product”). The configuration pattern 102 is a parameterized or otherwise easily extensible solution to that problem, such that the solution is reusable by modifying the parameters of the pattern or extending the pattern in well-defined ways. For example, slotting a card with 1+1 protection, i.e. for each card a second, identical card is required for redundancy, is a common configuration problem in which a card is slotted, with an additional protection card slotted adjacent to it. The modeling problem can be solved using a slot-card-with-1+1-protection configuration pattern. Thus, each time user input 108 makes a request to the configuration engine 106 for a card that requires 1+1 protection, the configuration engine 106 can use the model 104 and specifically the slot-card-with-1+1-protection configuration pattern of patterns 102 to determine if the request can be accommodated and a product configuration output 110 generated that slots the requested card plus a protection card. In general, the configuration engine 106 and model 104 describe the components and logic for configuring a complex product that satisfies a particular set of needs or request inputs. The Lynch/Franke Patent describes an example configuration engine 106 and its interaction with a general model.
  • The behavior of the model with configuration patterns when used by a configuration engine is determined in part by data provided by the product expert. For example, the data provides information that specifies values of attributes that influence the configuration solutions determined by a configuration engine when using the model. By separating the data that drives the configuration logic from generalized portions of the model representing generalized configuration logic, configuration models are easier to maintain and extend and reduce significant portions of the modeling process to essentially that of data entry by a product expert. Thus, pattern-based modeling allows the modeling process to be separated into two aspects: (1) development of the configuration product model based on a generalized modeling language (developed and maintained by modelers skilled in the particular modeling language) and (2) provision of product data that customizes a particular model for a particular product (maintained by product experts not necessarily skilled in the particular modeling language). The embodiment in aspect (1) above is a pre-packaged configuration model, which provides commonly-encountered configuration tasks and accepts a variety of data provided by the product expert. Once a model has been developed using patterns, some embodiments of the invention provide tools such as user interface 901 to a product expert that allow the product expert to customize the model through data entry.
  • Configuration Patterns.
  • Embodiments of pattern-based modeling provide, for example, the following benefits:
      • Simpler modeling—patterns help to decompose the problem of configuring a product; modeling is reduced to identifying the patterns that apply to the product and gathering the data required by the patterns.
      • Less custom code and more standardization—in the event that an exact pattern does not exist to address some configuration task, the amount of custom code required to model the configuration task is less when existing patterns are extended or a new pattern is created that uses existing patterns. Extending an existing pattern is generally no more complicated than overriding a small number of functions to implement the new, desired behavior.
      • Guidelines for good modeling—the guidelines and rules for creating patterns are often the result of years of modeling experience and are excellent guidelines to follow for creating models that are easy to maintain and extend.
      • Facilitating reuse and extensibility—new configuration patterns can be constructed from existing patterns.
      • Ease of maintenance—using patterns can reduce a significant amount of modeling to mainly a data-entry task by a product expert, or modeler working with a product expert.
      • Quality—patterns may be packaged as a product, instead of custom code, which allows for more rigorous quality engineering certification.
  • A configuration pattern can be reused to solve a variety of problems by changing the parameters of the pattern; an application of a configuration pattern is the parameterization of the pattern for a specific problem. Thus, applications of the pattern can be maintained as data. The data that drives the configuration pattern can be represented in XML or any other structured data format. Implementation of the pattern is done in any configuration engine modeling language with sufficient robustness and expressiveness to facilitate the desired model characteristics. Such modeling languages include Java™ from California based Sun Microsystems and CML, the configuration modeling language of Austin, Tex. based Trilogy Software, Inc.™.
  • The following is a list of properties of embodiments of configuration patterns:
    • 1. Data-Driven—configuration patterns are inherently data-driven (controlled); the behavior of an existing pattern is customized by supplying values, which are the definitions of components and resources, for the pattern attributes. This property makes it easy to maintain product-bases, i.e. a model that also contains information about elements available to configure a system, such as components and resources.
    • 2. Reusable—configuration patterns can be reused within and across different product families.
    • 3. Inheritable—configuration patterns can be specialized from other patterns.
    • 4. Constructive—generally, though not exclusively, patterns add components to the configuration or establish relationships among existing components in the configuration.
  • In general, patterns are essentially responsible for providing configuration logic to the configuration engine, whether it be slotting a card, configuring an amplifier card for an optical interface card, or configuring the high-speed interface lines and their supporting cards for an optical add-drop multiplexer. In response to a user input 108 configuration task related request, the configuration engine 106 applies the appropriate patterns 102 to components (not shown) in the configuration model, i.e. when a component is instantiated (i.e. created). Thus, the logic associated with the patterns 102 will be evaluated by the configuration engine 106 in the context of that component to perform the requested configuration task. Which pattern or patterns are appropriate for application is described in more detail below with reference to the applied_patterns 228 attribute. The “#” associated with an attribute name indicates that the attribute in the particular depicted embodiment is a protected attribute that can only be used by selected classes, such as descendent classes.
  • Product Hierarchy Model
  • In a configuration model that uses patterns, product domain knowledge will generally be defined in a product hierarchy model 200. FIG. 2 illustrates an example product hierarchy model. In one embodiment of product modeling hierarchy 200, which is explained in more detail in the Lynch/Franke Patent (particularly with reference to FIG. 3 of the Lynch/Franke Patent), the Component_Class 202 is the most general class or “thing” in the model; all other classes and components descend from the Component_Class 202. Each descendent class can inherit data and logic associated with higher-level classes through which a class descends. The example product modeling hierarchy 200 contains three base classes, Composite_Base_Class 204, Connector_Base_Class 206, and Container_Base_Class 208. The Component Class 202, Composite_Base_Class 204 and Part_Class_1 contain product data such as part-numbers, descriptions, and the type and number of ports provided by an optical interface card. Product modeling hierarchy 200 is further organized to contain derived classes such as Part_Class_1 210, Part_Class_2 212, Part_Class_3 214, and Part_Class_4 216. Part_Class_5 descends directly from Component_Class 202. Each Part_Class_X class represents broad component categories such as optical interface cards. Although only one generation of derived classes is shown, multiple generations of derived classes can descend from base classes. The Part_Classes terminate with component types, for example, Component_1 220, Component_2 222, Component_3 224, Component_4 226, Component_5 236. Component_6 238 descends directly from Component Class 202. Component types are generically referred to herein as “components”. Components_Y include actual components that can be instantiated and configured such as “OC-3 optical interface card with SC connectors”. When the configuration engine 106 utilizes a particular Part_Class_X of the product model 104 to comply with a user input 108, an instantiated member, Component_Y, of the particular Part_Class_X is created.
  • The Component_Class 202 also contains data related to the configuration patterns 218 that it can apply. In one embodiment, for each class and component in the product modeling hierarchy 200 the attribute “applied_patterns 228” specifies which configuration patterns 218 will be applied. For each class and component in the product modeling hierarchy 200 attributes “required_patterns 232” and “optional_patterns 230” define the required patterns and optional patterns, respectively. The attribute applied_patterns 228 is the union of the required_patterns 232 and optional_patterns 230, filtered to remove exclusive patterns and sorted by pattern application priority, which provides an ordering on the patterns. Pattern application ordering can be indicated in any manner using any techniques including numerical techniques, non-numeric partial orders, represented by directed graph structures, and other reference techniques. In other embodiments, ConfigurationPatterns 218 descend from other members of the product modeling hierarchy 200. By descending from the highest node of product modeling hierarchy 200, all classes and components of product modeling hierarchy 200 are able to apply ConfigurationPatterns 218 through inheritance.
  • In one embodiment, those configuration patterns 218 specified in required_patterns 232 are always applied to the class (or component) the attribute is set on. Configuration patterns 218 specified in optional_patterns 230 can be, but do not have to be applied. In this embodiment, only the applied configuration patterns 218 are evaluated (applied) during creation or instantiation of the component. In one embodiment, product managers enter data on individual components and select those patterns that are applicable to the selected components using, for example, the data entry displays discussed in conjunction with FIGS. 9A, 9B, and 9C.
  • Choice of a particular pattern is made by matching the functions of existing patterns to the configuration needs of a component. For example, an optical interface card might have the following patterns selected for application to the components in the product hierarchy model 200 associated with an optical interface card:
      • SlotCard—responsible for finding a slot for the card in a shelf or rack, given the characteristics of the card.
      • AmplifyOpticalSignal—responsible for configuring an optical amplifier card, given characteristics of the card, the fiber that it is connected to, and the network or which it is a part.
  • Other example optical related configuration patterns are listed below:
      • FilterSlotsByHighSpeedInterface—this filter is used by the SlotCard pattern to select slots for an optical interface card or optical amplifier card based on the specific network application that the card supports, and the fiber link within that network application.
      • ConfigureInterfaceCard—the ConfigureInterfaceCard pattern (a sub-pattern of the RequiresResourceProvider pattern, described below) is used by an interface-card requirement component to instantiate one or more interface cards, based on the type of interface (DS-1, DS-3, Ethernet, OC-12, OC-48, etc.), and the type of interface card (tributary, transmitter, receiver, etc).
      • ConfigureElectricalInterfaceCard—the ConfigureElectricalInterfaceCard pattern (a sub-pattern (descendent) of the ConfigureInterfaceCard pattern) is used by an electrical interface-card requirement component to instantiate one or more electrical interface cards, based on the type of interface (DS-1, DS-3, Ethernet, etc.), and the type of interface card (tributary, transmitter, receiver, etc).
      • ConfigureOpticalInterfaceCard—the ConfigureOpticalInterfaceCard pattern (a sub-pattern (descendent) of the ConfigureInterfaceCard pattern) is used by an optical interface-card requirement component to instantiate one or more optical interface cards, based on the type of optical interface (OC-3, OC-12, OC-48, etc.).
      • ConfigureElectricalTributary—the ConfigureElectricalTributary pattern (a sub-pattern of the ConfigureElectricalInterfaceCard pattern) is used by an electrical tributary requirement component to instantiate one or more electrical interface cards with or without protection, based on the type of interface (DS-1, DS-3, Ethernet, etc.). These cards are generally used to drop bandwidth in an add/drop multiplexer or cross connect.
      • ConfigureOpticalTributary—the ConfigureOpticalTributary pattern (a sub-pattern of the ConfigureOpticalInterfaceCard pattern) is used by an optical tributary requirement component to instantiate one or more optical interface cards with or without protection, based on the type of optical interface (OC-3, OC-12, OC-48, etc.). These cards are generally used to drop bandwidth in an add/drop multiplexer or cross connect.
      • ConfigureHighSpeedInterfaceCard—the ConfigureHighSpeedInterfaceCard pattern is used by a high-speed interface card requirement to configure the high-speed interface cards that connect a network element (node) to a network. A network application is defined by a certain number of high-speed interface card requirements. Example network applications include UPSR, BLSR (two-fiber and four-fiber), Terminal, and Regenerator (two-fiber and four-fiber).
      • RequiresDispersionCompensation—the RequiresDispersionCompensation pattern (a sub-pattern of the ConfigureSupportingCard pattern), is used by an optical-interface card (the compensated card), to configure a dispersion compensation card (the compensating card). The compensated card requires the compensating card to compensate for chromatic dispersion (distortion of the signal because different frequencies of the signal have different propagation characteristics), and other dispersion types, of the optical signal over long distances.
      • RequiresOpticalConnectorAdapterKit—the RequiresOpticalConnectorAdapterKit pattern is used to configure a connector adapter kit when the connector of the card using the pattern is different from the required connector, or when the card using the pattern does not have a specific connector type.
  • Example general patterns are listed below:
      • ConfigureBundle—the ConfigureBundle pattern is used to instantiate a bundle or kit of components that always come with the component applying the pattern. An example of a bundle or kit is the bracket, nuts and bolts for attaching a shelf to a rack.
      • RequiresResourceProvider—the RequiresResourceProvider pattern is used by a component to instantiate one or more instances to satisfy a requirement for a specific resource and quantity. This pattern is typically an abstract pattern; meaning that it is not used directly, but is used by other patterns. Examples of patterns that might use this pattern are those that configure interface cards by the type of port (resource) provided by the card.
      • Containment—the Containment pattern is used by a component (the containee) that needs to be placed into a container (the container).
      • DateEffectivityFilter—this filter is used by configuration patterns to only select components for instantiation that are effective for a given point of time, usually the current day.
      • FilterSlotsByExplicitList—this filter is used by the SlotCard pattern to only select slots that are members of an explicit list of slots.
      • FilterSlotsByShelf—this filter is used by the SlotCard pattern to only select slots that are in a certain type of shelf.
      • FilterSlotsByOddEvenPosition—this filter is used by the SlotCard pattern to only select slots that have an even or odd slot position, but not both.
      • FilterSlotsByGroup—this filter is used by the SlotCard pattern to slot the card in a specific slot group. A slot group is a collection of slots, usually related by physical proximity.
      • ConfigureSupportingCard—the ConfigureSupportingCard pattern is used by a card (the supported card) to instantiate another card (the supporting card). The supported card requires the supporting card for its correct operation.
      • ConfigureProtectionCard—the ConfigureProtectionCard pattern (a sub-pattern of the ConfigureSupportingCard pattern) is used by a card (the protected card) to instantiate another card (the protecting card). The protected card requires the protecting card for redundancy and/or fail-over.
  • Pattern Hierarchy Definition
  • In one embodiment, all configuration patterns that are relevant for a certain configuration model are defined in a pattern hierarchy 300 illustrated in FIG. 3. A pattern hierarchy is used, for example, to achieve programming efficiency by allowing patterns to inherit common functions and attributes while allowing customization in descendent patterns through addition of functionality and attributes. Descendent patterns may also override all or a portion of inherited functionality and attributes.
  • The pattern hierarchy 300 contains a general pattern class referred to as ConfigurationPattern 302 and descendent pattern classes 304 that descend from ConfigurationPattern 302 and inherit ancestor class attributes. Example descendent pattern classes 304 are RequiresResourceProvider 306 and ConfigureSupportingCard 308, which descends directly from ConfigurationPattern 302, and ConfigureInterfaceCard 310, which descend directly from RequiresResourceProvider 306. The ConfigureOpticalInterfaceCard 312 and ConfigureElectricalInterfaceCard 314 patterns descend directly from the ConfigureInterfaceCard 310 pattern. The descendent pattern classes 304 are described above.
  • A pattern can be defined for (and applied to) disjoint hierarchies within the product modeling hierarchy 200, i.e. to any class or component in the product modeling hierarchy 200. In the embodiment depicted in FIG. 3, ConfigurationPatterns 302 is applied to Component_Class 322. If the ConfigurationPatterns 302, as defined in the product model 104, completes successfully, i.e. the configuration is valid, the instance of the ConfigurationPatterns 302 is deleted to free up memory for future configuration evaluations. In one embodiment, a transient property is established to delete ConfigurationPattern 302. This property can be inherited through any descendent of ConfigurationPatterns 302.
  • The optical application pattern hierarchy 300 example provides an example of how a component instance applies patterns. Patterns are applied to components such that the logic associated with the pattern is used by the component to perform some configuration task. Access to the instance for which the pattern is being evaluated, or the component that is using the pattern, is given by the _pattern_context_CI 318 attribute, which is an inverse attribute of the attribute _pattern_CI 320, which points to the pattern being evaluated. The component applying the pattern depicted in FIG. 3 is _pattern context_Cl:Component_Class 322. ConfigurationPatterns 302 could also be applied, for example, to any descendent of Component_Class 202, such as Composite_Base_Class 204, Connector_Base_Class 206, Container_Base_Class 208, Part_Class_X, or Component_Y.
  • A pattern preferably does not contain any product data as part of its definition so as to allow patterns to be applied freely without being constrained by specific product data. All product and domain specific data is preferably defined in the product hierarchy model 200, as described above.
  • For each pattern, the attribute pattern_application_priority_F 324, which is in one embodiment a floating point variable, specifies an ordering over the patterns that are applied to a component to control the dependencies between patterns. Patterns 218 with higher values are applied first in one embodiment. For example, the SlotCard pattern must be evaluated before the ConfigureProtectionCard pattern, since the ConfigureProtectionCard pattern requires that the card that requires protection is slotted.
  • Patterns 218 can be mutually exclusive because certain components in the product hierarchy model 200 may not have the same pattern behavior (configuration logic) of two different patterns at the same time. Therefore, for each pattern, the attribute exclusive_patterns_mCL 326 specifies which patterns are mutually exclusive with the pattern.
  • Patterns can also be used to do global and contextual filtering and initializations. This is logic that can be applied to all instances and candidate components for instantiation or a subset of instances and candidate components for instantiation that satisfy some context in the product. The global and contextual filtering could include effectivity filtering for determining when a particular component candidate for instantiation can be configured and initialization of component instance attributes after instantiation. Filters provide a way to customize the behavior of a pattern in pre-defined ways by adding filters to a multi-valued list that is applied by all patterns. Similarly, initializers can provide a way to initialize attributes on instances created by or used by all patterns. The PatternFilter 328 and PatternInitializer 330 classes are provided for this purpose. PatternFilter 328 and PatternInitializer 330 classes implement the IPatternFilter and IPatternInitializer interfaces, respectively, to perform the predetermined filtering and initialization.
  • The pattern_filters_mCL attribute 332 contains a list of filters to be applied by the pattern for global filtering and the pattern_initializers_mCL 334 attribute contains a list of initializers to be applied by the pattern for global initializations. In one embodiment, the attributes pattern_filters_mCL attribute 332 and pattern_initializers_mCL 334 should only be used for global and contextual filtering and initialization with pattern specific filtering and initialization being performed via interfaces specific to the pattern. More details on filtering and initialization are provided below.
  • Example Pattern Application and Evaluation
  • The following section describes one embodiment of the application and evaluation of patterns for configuration. When a component is created or instantiated, all specified patterns (listed in applied_patterns 228) will be created and evaluated in the order in which they appear in the list. The specific pattern logic (configuration logic) depends on the pattern.
  • The attribute applied_patterns 228 is evaluated by configuration engine 106 (i.e. pattern instances will be created) for all components, according to the following rules:
    • 1. Uniqueness: It is preferably illegal to apply any pattern in conjunction with one or several of its derived patterns. Out of each branch in the pattern hierarchy 300 only one pattern, the most specific pattern, will be evaluated.
    • 2. Sequence: The modeler will specify the order of patterns in a declarative manner using the patter_application_priority_F attribute.
  • In one embodiment, an instance of a configuration pattern is a transient object. It will be instantiated, then evaluated, and upon completion it will be deleted to free available memory space. When a pattern is created, the attribute_pattern_context_CI 320 will be set to keep track of the instance for which this pattern is being evaluated, and the attribute _pattern_CI 318 will be set to the pattern that is being evaluated.
  • The following is an example of establishing instance dependencies during pattern application. Whether a configuration engine 106 utilizes instances of components is a matter of design choice but can be preferable for controlling memory usage. Additionally, by creating multiple instances of a component, each instance of the component can be assigned different attribute values.
  • When an instance A, such as a working interface card, requires an instance B, such as a protection card for the working interface card, it is said that A “depends on” B, such that if B is deleted, A should be deleted as well. Dependencies between different instances (between the instance on which the patterns are applied and the instance(s) being created) will be established as described below. There will never be any dependencies on pattern instances because pattern instances only exist temporarily and are deleted after evaluation.
  • The following approach can be used to establish dependencies:
  • Consider that A is a component instance that has pattern instances {P1, P2, . . . , Pn} associated with it. If in the process of evaluating the logic for P1, a component instance B is created, configuration engine 106 performs the following:
    • 1. A establishes a dependency on B; and, if applicable,
    • 2. B establishes a dependency on A.
  • This dependency will be established as follows:
    • 1. Create pattern instance P1.
    • 2. In the logic for the pattern P1, instantiate instance B.
    • 3. Establish dependencies between instance A (the pattern context) and instance B whereby A establishes the dependency on B.
  • Filters and Initializers
  • In one embodiment, filters and initializers can be of two forms:
    • 1. Global—global filters are applied to all candidate components for instantiation and instances to do such things as effectivity dating filtering. Thus, the function for doing the filtering need only be written once, and applied where needed. These filters can be applied for every instance, candidate component for instantiation, or for any subset of instances.
    • 2. Context—it is often that case that a component candidate for instantiation or instance is only valid in a certain state or context; for example, OC-48interface card oc48_card1 may be needed if there are OC-3tributaries in the product, while card oc 48_card2 may be needed if there are not OC-3tributaries in the product. These filters can be applied for every component of the given type.
  • Referring to FIGS. 3 and 4, the ConfigurationPattern 302 class uses the interface IConfigurationPattern 400 to filter and initialize component instances or candidate components for instantiation. In one embodiment, the IConfigurationPattern 400 contains two functions:
      • isValid( )—The purpose of the isValid( ) function is to determine if an instance or candidate component for instantiation is valid in the context of a pattern. By default, the isValid( ) function iterates over all the filters applied to the pattern. Versions of this function exist for instances and candidate components for instantiation. The “boolean” nomenclature in the context of FIG. 4 and similar figures indicates that the function evaluates to either “true” or “false”.
      • initialize( )—The purpose of the initializes( ) function is to initialize attributes on the instantiated instance. By default, the initializes( ) function iterates over all the initializers applied to the pattern.
  • Referring to FIG. 5, the PatternFilter class 328 (FIG. 3) uses the interface IPatternFilter 500 to implement filtering logic. Each sub-class of the PatternFilter class 328 overrides the functions in the IPatterFilter interface to implement the logic specific to that filter.
  • In one embodiment, IPatternFilter 500 contains one function:
      • isValid( )—The purpose of this function is to determine if a component instance or candidate component for instantiation is valid in the context of a filter. By default, the function returns TRUE. Versions of this exist for instances and candidate components for instantiation.
  • An example implementation of the isValid( ) function for effectivity-dating filtering:
    class DateEffectivityFilter : PatternFilter{ }
    function Boolean isValid on DateEffectivityFilter(Component candidate)
    {
    //The candidate attribute is a candidate for instantiation by some
    pattern.
    //Its effectivity range, defined by the attributes
    effectivity_start_date and
    //effectivity_end_date must include the current date.
    if(
    current-date<=candidate.effectivity_end_date
    AND
    current-date>=candidate.effectivity_start_date
    )then
    return TRUE
    else
    return FALSE
    }
  • Referring to FIG. 6, the PatternInitializer class 600 uses the interface IPatternInitializer (FIG. 3) to implement the initialization logic. Each sub-class of the PatternInitializer class 600 overrides the functions in the IPatternInitializer interface to implement the logic specific to that initializer.
  • In one embodiment, PatternInitializer class 600 contains one function:
      • initialize( )—The purpose of this function is to initialize attributes on the instantiated instance. By default, the function returns TRUE.
  • Pattern Activity
  • FIG. 7 presents a summary of the descriptions above by illustrating the activity of a pattern on a component. Each component has a list of patterns that it needs to apply, stored in the attribute applied_patterns 702. The diagram in FIG. 7 illustrates the application of a single pattern in this list; this activity is repeated for each element of the list. The component instance applying the patterns is denoted _pattern_context_CI 704. For simplification, the pattern illustrated in this diagram simply instantiates another component, _dependent_instance_CI: Component 708. An example pattern that demonstrates the activities depicted in FIG. 7 is a pattern that configures an amplification card for an optical interface card, based on the fiber type and span of a transmission line. It will be apparent to those of ordinary skill in the art that more complicated patterns can be created using the principles of pattern application depicted in FIG. 7 and described below.
  • The configuration engine 106 evaluates the patterns stored in the attribute applied_patterns 228 (FIG. 2). The pattern, Configuration_Pattern 716, is instantiated (message instantiate( ) 703 from the _pattern_context_CI 704 to Configuration_Pattern 716), and then applies pattern logic contained in Configuration_Pattern 716 to _pattern_context_CI 704 (message applyPatternLogic( ) from the pattern to the context). The logic involved in this Configuration_Pattern 716 involves instantiating _dependent_instance_CI: Component 708 using the instantiate( ) message 709. Because of the transitory nature of the pattern instance, configuration engine 106 establishes dependency between _dependent_instance_CI: Component 708 and _pattern_context_CI 704 via the establishDependency( ) message. This dependence can be used so that if any dependent instances were to be deleted, the _pattern_context_CI component 704 would be deleted as well, as described previously. Once the dependency is established the pattern logic of Configuration_Pattern 716 is complete (the return( ) message 713) and Configuration_Pattern 716 is destroyed (the destroy( ) message 714).
  • As the diagram shows, pattern instances are transient objects that live only as long as necessary to achieve the task they are designed to perform.
  • Identifying Patterns
  • In pattern-based configuration, the primary task of the modeler becomes studying the product to be modeled and identifying the patterns that are necessary for configuring the product. Patterns are identified by recognizing generally repetitive tasks that occur over and over again across product families. This introduces a level of abstraction that was not previously available.
  • Some common patterns that are used in configuring optical telecommunications equipment are the following:
    • 1. Card Slotting—Optical interface cards (OC-3, OC-12, etc.) and “common” cards (CPUs, memory, power cards, etc) must be placed into slots in a shelf or card cage, subject to provisioning rules such as:
      • (a) Cards can only go into certain slots (even slots only, slots numbered 1, 2, 3, 4, etc).
      • (b) Cards are slotted in a left-to-right, right-to-left, etc. manner.
      • (c) Cards are slotted in a specific shelf (high-speed transport shelf, management shelf, tributary shelf, etc.).
      • (d) Cards are slotted in groups or quadrants (a tributary card that is used on the working high-speed line is slotted in quadrant 1 slots 1,2, 3, 4).
    • 2. Protection—To support redundancy and fail-over, optical cards are often configured with protection of the following types:
      • (a) 1+1—each working card requires a protection card.
      • (b) 1×N—each set of N working cards requires a protection card.
        Protection also impacts slotting provisioning rules. For example, 1+1 protection may require that the working card be placed in an odd-numbered slot and the protection card in the adjacent even-numbered slot to the right.
    • 3. Amplification—In optical networking, amplification is often needed when transmitting a signal over long distances. The rules for configuring amplification cards include the following:
      • (a) Minimum span—the span, or distance between nodes on a network is one of the primary determining characteristics as to whether amplification is needed.
      • (b) Fiber type—the type of fiber can determine the type of amplification card needed and the span for which amplification is required.
  • A list of broad patterns for a particular domain is usually easily identifiable with experience in configuring products in that domain. The details and specifics of the patterns can be discovered with the help of product expert(s).
  • Consider the task of configuring an OC-48optical interface card that requires the patterns identified above. Without using patterns, custom code would need to be written for each component or class. An example is shown below. This is time-consuming and error prone. A similar function would need to be written, and tested for each type of component. This function assumes a number of support functions, not shown, to implement smaller pieces of configuration logic. These support functions would also need to be developed and maintained, increasing the complexity of the overall modeling task. These support functions are indicated below.
    function configureOC48Card( )
    {
    if card-requires-slotting  // support function
    oc48-slots=available slots for this-card // support function
    for each sloti in set of oc48-slots
    if sloti is-compatible-with this-card // support function
    place this-card in sloti //support function
    if no-slot-found return-with-failure
    if card-requires-protection // support function
    instantiate protection-card // support function
    if card-requires-1+1-protection
    protection-slots=available 1+1 slots // support function
    if card-requires-1xn-protection
    protection-slots=available 1xn slots // support function
    if protection-slots is empty
    continue
    else
    for each slotj in protection-slots
    place protection-card in slotj //support function
    if card-requires-amplification  // support function
    if span of this-card>span-required-for-amplfication
    instantiate amplification-card  // support function
    place amplification-card in some slot  // support function
    }
  • Alternatively, the following segment shows how this problem would be solved using configuration patterns.
    define-component
    name: OC48-1
    type: OC48InterfaceCard
    applied_patterns={
    SlotCard,
    ConfigureProtectionCard,
    AmplifyOpticalSignal
    }
    //
    // Define the attributes for the SlotCard pattern
    //
    slot_type=InterfaceCardSlot
    slot_sorting_direction=Left-To-Right
    //
    // Define the attributes for the ConfigureProtectionCard pattern
    //
    protection_type=1+1
    //
    // Define the attributes for the AmplifyOpticalSignal pattern
    //
    minimum_amplification_distance=10km
    amplifier_card_type=OpticalAmplifierCard
  • Each pattern applied to the component above assumes certain data set on a component, as shown in the example.
  • Given that an optical interface card generally requires amplification, the AmplifyOpticalSignal pattern simplifies the task of gathering information. Patterns help to focus attention on what information needs to be collected to accurately configure the product. For example, the AmplifyOpticalSignal pattern requires the following information:
    • 1. The minimum distance at which amplification is required, given by the attribute minimum_amplification_distance attribute above.
    • 2. The type of amplifier card needed, given by the attribute amplifier_card_type above.
  • Using patterns, a simple data sheet can be constructed to help gather information for patterns. A sample data sheet for tributary cards is shown in FIG. 9. This data sheet can be used by a product expert, or by a modeler working with a product expert, to gather the attributes for a pattern. It can also be used to identify the gaps in the logic of existing patterns.
  • Pattern identification requires a moderate level of product knowledge, and the ability to implement configuration logic, either extensions of existing patterns, or new patterns, using the modeling language of a configuration engine.
  • Creating Patterns
  • Rules for Creating Patterns
    • 1. Define a class descended from ConfigurationPattern.
    • 2. If the class defined in 1. is a specialization of an existing pattern, override the necessary functions to implement the desired behavior.
    • 3. If the class defined in 1. is not a specialization of an existing pattern, implement the pattern logic as necessary.
    • 4. Whenever the pattern logic instantiates a new component, correct dependencies can be established as described previously.
    • 5. When filtering instances or candidate components for instantiation, call the isValid( ) function on the pattern to take into account global and contextual filtering.
    • 6. When instantiating instances, call the initialize( ) function on the pattern to take into account global and contextual initializations.
  • Pattern Development Guidelines
    • 1. Because patterns do not have any product-specific data associated with them, all logic-driving data is stored on the pattern context (_pattern_context_CI).
    • 2. Functions that support the logic of the pattern are to be written on the pattern class. This includes such things as filtering, initialization, and determining whether or not a piece of pattern logic is to be applied.
    • 3. Functions that return data may be written on the product class. This may include such things as returning values for sorting, and returning data that drives the pattern logic. Default implementations must be provided for all functions.
    • 4. Any global or contextual filtering and initialization should be implemented by adding the appropriate filters and initializers to the pattern_filters_mCL and pattern_initializers_mCL attributes of the top-level ConfigurationPattern class. Note: Filters and initializers can be added to the pattern_filters_mCL and pattern_initializers_mCL attributes of descendents of the ConfigurationPattern class. Preferably, such filters and initializers are implemented as part of the pattern interface.
    EXAMPLE
  • FIG. 8 illustrates the ConfigureOpticalInterfaceCard pattern 802. The ConfigureOpticalInterfaceCard pattern 802 is used to instantiate one or more optical interface cards 801, based on the type of optical interface (OC-3, OC-12, OC-48, etc) required. The ConfigureOpticalInterfaceCard pattern 802 could be used to, for example, satisfy the requirements of an optical tributary or a high-speed interface.
  • The characteristics of the required optical interface card 801 are specified by the attributes in the OpticalInterfaceCardRequirement 804 component, as shown in the diagram. Specifically, optical interface cards may be described by the following:
      • Card type—the type of optical interface card required, specified by the card_required_CL 815 attribute on the OpticalInterfaceCardRequirement 804 component.
      • Number of ports required—the number of ports required from the optical interface card, specified by the ports_required_F attribute on the OpticalInterfaceCardRequirement 804 component.
      • Bit rate—the bit rate required from the optical interface card, specified by the bitrate_required_R 805 attribute on the OpticalInterfaceCardRequirement 804 component.
      • Fiber type—the type of fiber supported by the optical interface card, specified by a fiber type resource provided by the card. The fiber type requirements are specified by the fiber_type_R 807 attribute on the OpticalInterfaceCardRequirement 804 component.
      • Connector type—the type of connector supported by the optical interface card, specified by a connector type resource provided by the card. The connector type requirements are specified by the connector_type_R 809 attribute on the OpticalInterfaceCardRequirement 804 component.
      • Wavelength plan—a group of wavelengths, specified by wavelength resources provided by the optical interface card(s) 801. The wavelength plan requirements are specified by the wavelength_plan_C 811 attribute on the OpticalInterfaceCardRequirement 804 component; the attribute wavelengths_mR on the WavelengthPlan class 803 list the wavelengths in the wavelength plan.
      • Span—the range, within which the interface card can operate, specified by the span_min_range_F 815(inclusive) and span_max_range_F 817 (exclusive) attributes on the optical interface card(s) 801. The span requirements are specified by the span_F 818 attribute on the OpticalInterfaceCardRequirement 804 component.
      • Interface type—the type of interface (transmitter, receiver, transceiver) provided by the optical interface card. The interface type requirements are specified by the interface_type_R 819 attribute on the OpticalInterfaceCardRequirement 804 component.
  • For configuring optical interface cards without customizations:
    • 1. In one embodiment, define cards descended from the OpticalInterfaceCard 808 class, with the following resources and attribute values:
      • [REQUIRED] provide resources of type OpticalCarrierResource 810 (or its descendents).
      • [REQUIRED} provide resources of type InterfaceTypeResource 812 (or its descendents).
      • [OPTIONAL] provide resources of type WavelengthResource 814 (or its descendents).
      • [OPTIONAL] provide resources of type FiberTypeResource 816 (or its descendents).
      • [OPTIONAL] values for the min_span_range_F and max_span_range—F attributes.
      • [OPTIONAL] provide resources of type ConnectorTypeResource 818 (or is descendents).
    • 2. Request an instance of an OpticalInterfaceCardRequirement 804 component class:
      • Initialize the attributes for card type, number of ports required, bit rate, fiber type, connector type, wavelength plan, and span to match the requirements of the optical interface card.
  • The IConfigureOpticalInterfaceCard interface contains functions that can be overridden by patterns that specialize this pattern. Patterns generally include interfaces to make extending the patterns easier. An example of a pattern that would override the ConfigureOpticalInterfaceCard pattern 802 is the ConfigureOpticalTributary pattern, which includes the option of whether or not the card needs to be protected. Creating the ConfigureOpticalTributary pattern is simply a matter of overriding a single function to initialize attributes on the instantiated interface card, indicating whether or not protection is needed.
  • Product Expert-Data Entry
  • Referring to FIGS. 9A, 9B, and 9C (collectively FIG. 9), as stated above once a model has been developed using patterns, some embodiments of the invention provide tools to a product expert that allow the product expert to customize the model through data entry. FIG. 9 presents an example computer interface that could be presented to a product expert for entering data associated with an optical tributary card. As the product expert proceeds to provide the data requested in user interfaces 901A, 90 1B, and 901C (collectively referred to as “user interface 901”), the data entered by the product expert would be used to populate the product model 104 with data for use by configuration engine 106 during configuration of a product.
  • Referring to FIGS. 1, 9, and 10, in one embodiment the configuration engine 106 uses a compiled version of product model 104, referred to as a product base 1002. Different configuration engines are designed to use configuration logic and data information in different formats. In one embodiment of configuration engine 106, such as the configuration engine described in the Lynch/Franke Patent, it is preferable that product model 104 be compiled into a product base 1002. In the embodiment set forth in FIG. 10, the compilation operation 1004 functions to compile the product data 1006, configuration patterns 102, product modeling hierarchy 200 of product model 104 into product base 1002, which is directly useable by configuration engine 106. In this embodiment, the product base 1002 becomes the product model utilized by configuration engine 106 to generate a product configuration. In other embodiments, product model 104 may be created in a state that is directly useable by configuration engine 106.
  • Configuration System Distribution
  • Referring to FIG. 11, a method of distributing the configuration system 100 incorporating the product model 104 with configuration patterns 102 to multiple enterprise users is shown. The configuration system 100 includes the configuration engine 116 and the product model 104. The configuration system 100 is copied and distributed to a plurality of different enterprises, such as first enterprise 1102, second enterprise 1104, and Nth enterprise 1 106. As illustrated, the configuration system 100 may be distributed to several different enterprises. Once the configuration system 100 has been distributed, each of the enterprises may use the system 200 to build product specific and company specific configuration models for use in software enabled configurations of various selected products. Each enterprise, by adding specific product data, can customize the configuration system for such enterprise's specific needs. The configuration system 100 may be embedded into an article of manufacture, such as a tape or other software storage device or tangible medium.
  • FIG. 12 is a block diagram illustrating a network environment in which the configuration system 100 and modeling may be practiced. Network 1202 (e.g. a private wide area network (WAN) or the Internet) includes a number of networked server computer systems 1204(1)-(N) that are accessible by client computer systems 1206(1)-(N), where N is the number of server computer systems connected to the network. Communication between client computer systems 1206(1)-(N) and server computer systems 1204(1)-(N) typically occurs over a network, such as a public switched telephone network over asynchronous digital subscriber line (ADSL) telephone lines or high-bandwidth trunks, for example communications channels providing T1 or OC 3service. Client computer systems 1206(1)-(N) typically access server computer systems 1204(1)-(N) through a service provider, e.g., an Internet service provider such as America On-Line™, and the like by executing application specific software, commonly referred to as a browser, on one of client computer systems 1206(1)-(N).
  • Client computer systems 1206(1)-(N) and/or server computer systems 1204(1)-(N) may be, for example, computer systems of any appropriate design, including a mainframe, a mini-computer, a personal computer system, or a wireless, mobile computing device. These computer systems are typically information handling systems, which are designed to provide computing power to one or more users, either locally or remotely. Such a computer system may also include one or a plurality of input/output (“I/O”) devices coupled to the system processor to perform specialized functions. Mass storage devices such as hard disks, CD-ROM drives and magneto-optical drives may also be provided, either as an integrated or peripheral device. One such example computer system is shown in detail in FIG. 13.
  • Embodiments of the configuration system 100 and modeling processes can be implemented on a computer system such as a general-purpose computer 1300 illustrated in FIG. 13. Input user device(s) 1310, such as a keyboard and/or mouse, are coupled to a bi-directional system bus 1318. The input user device(s) 1310 are for introducing user input to the computer system and communicating that user input to processor 1313. The computer system of FIG. 13 also includes a video memory 1314, main memory 1315 and mass storage 1309, all coupled to bi-directional system bus 1318 along with input user device(s) 1310 and processor 1313. The mass storage 1309 may include both fixed and removable media, such as other available mass storage technology. Bus 1318 may contain, for example, 32 address lines for addressing video memory 1314 or main memory 1315. The system bus 1318 also includes, for example, an n-bit DATA bus for transferring DATA between and among the components, such as CPU 1309, main memory 1315, video memory 1314 and mass storage 1309, where “n” is, for example, 32 or 64. Alternatively, multiplex DATA/address lines may be used instead of separate DATA and address lines.
  • I/O device(s) 1319 may provide connections to peripheral devices, such as a printer, and may also provide a direct connection to a remote server computer systems via a telephone link or to the Internet via an internet service provider (ISP). I/O device(s) 1319 may also include a network interface device to provide a direct connection to a remote server computer systems via a direct network link to the Internet via a POP (point of presence). Such connection may be made using, for example, wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like. Examples of I/O devices include modems, sound and video devices, and specialized communication devices such as the aforementioned network interface.
  • Computer programs and data are generally stored as instructions and data in mass storage 1309 until loaded into main memory 1315 for execution. Computer programs may also be in the form of electronic signals modulated in accordance with the computer program and data communication technology when transferred via a network. The method and functions relating to configuration system 100 and modeling processes may be implemented in a computer program alone or in conjunction with hardware implementations. Furthermore, context subsystem data structures can be implemented in CPU 1300 and utilized by CPU 1300 or by other data processing systems that have access to the data structures.
  • The processor 1313, in one embodiment, is a 32-bit microprocessor manufactured by Motorola, such as the 680100 processor or microprocessor manufactured by Intel, such as the 801086, or Pentium processor. However, any other suitable single or multiple microprocessors or microcomputers may be utilized. Main memory 1315 is comprised of dynamic random access memory (DRAM). Video memory 1314 is a dual-ported video random access memory. One port of the video memory 1314 is coupled to video amplifier 1316. The video amplifier 1316 is used to drive the display 1317. Video amplifier 1316 is well known in the art and may be implemented by any suitable means. This circuitry converts pixel DATA stored in video memory 1314 to a raster signal suitable for use by display 1317. Display 1317 is a type of monitor suitable for displaying graphic images.
  • The computer system described above is for purposes of example only. The configuration system 100 and modeling processes may be implemented in any type of computer system or programming or processing environment. It is contemplated that the configuration system 100 and modeling processes might be run on a stand-alone computer system, such as the one described above. The configuration system 100 and modeling processes might also be run from a server computer systems system that can be accessed by a plurality of client computer systems interconnected over an intranet network. Finally, the configuration system 100 and modeling processes may be run from a server computer systems that is accessible to clients over the Internet.
  • Many embodiments of the present invention have application to a wide range of industries including the following: computer hardware and software manufacturing and sales, professional services, financial services, automotive sales and manufacturing, telecommunications sales and manufacturing, medical and pharmaceutical sales and manufacturing, and construction industries.
  • The above disclosed subject matter is to be considered illustrative and the appended claims are intended to cover all such modifications and other embodiments which fall within the true spirit and scope of the present invention. For example, although the use of patterns within the framework of product hierarchies and pattern hierarchies may be preferable, depending, for example, on the particular configuration system being used, patterns do not have to be used in conjunction with product hierarchies and pattern hierarchies. They can be used in virtually any instance where a solution to a configuration problem repetitively occurs. To the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents and shall not be restricted or limited by the foregoing detailed description.

Claims (2)

1. A configuration model for use with a product configuration software system, the configuration model comprising:
configuration patterns having configuration logic for performing tasks related to a configuration of a product.
2.-43. (canceled)
US11/552,756 2001-12-28 2006-10-25 Product configuration using configuration patterns Abandoned US20070094641A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/552,756 US20070094641A1 (en) 2001-12-28 2006-10-25 Product configuration using configuration patterns

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US34367001P 2001-12-28 2001-12-28
US34366601P 2001-12-28 2001-12-28
US10/099,404 US7188335B1 (en) 2001-12-28 2002-03-15 Product configuration using configuration patterns
US11/552,756 US20070094641A1 (en) 2001-12-28 2006-10-25 Product configuration using configuration patterns

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/099,404 Continuation US7188335B1 (en) 2001-12-28 2002-03-15 Product configuration using configuration patterns

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/396,705 Continuation US7810929B2 (en) 2003-04-10 2009-03-03 Optical system for a fundus camera

Publications (1)

Publication Number Publication Date
US20070094641A1 true US20070094641A1 (en) 2007-04-26

Family

ID=37807291

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/099,404 Expired - Lifetime US7188335B1 (en) 2001-12-28 2002-03-15 Product configuration using configuration patterns
US11/552,756 Abandoned US20070094641A1 (en) 2001-12-28 2006-10-25 Product configuration using configuration patterns

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/099,404 Expired - Lifetime US7188335B1 (en) 2001-12-28 2002-03-15 Product configuration using configuration patterns

Country Status (1)

Country Link
US (2) US7188335B1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060005177A1 (en) * 2004-06-30 2006-01-05 International Business Machines Corp. Method, system and program product for optimizing java application performance through data mining
US20080098355A1 (en) * 2006-09-29 2008-04-24 Sap Ag Integrated configuration of cross organizational business processes
US20090144702A1 (en) * 2004-06-30 2009-06-04 International Business Machines Corporation System And Program Product for Determining Java Software Code Plagiarism and Infringement
US20100049857A1 (en) * 2007-04-13 2010-02-25 Scott Allan Libert System software productization framework
US20110231813A1 (en) * 2010-03-19 2011-09-22 Seo Sun Ae Apparatus and method for on-demand optimization of applications
US8245020B1 (en) * 2008-05-13 2012-08-14 Selectica, Inc. Creating a partial instance of component in response to user specifying a value for a dynamic attribute of a selected component
US8965831B2 (en) 2012-07-27 2015-02-24 Selectica, Inc. System, method, and software program product for enabling users to create and use rule patterns to generate custom product-configuration rules
US20160124718A1 (en) * 2014-11-05 2016-05-05 Oracle International Corporation Context-based generation of memory layouts in software programs
US10275154B2 (en) 2014-11-05 2019-04-30 Oracle International Corporation Building memory layouts in software programs
US10353793B2 (en) 2014-11-05 2019-07-16 Oracle International Corporation Identifying improvements to memory usage of software programs
US20190265992A1 (en) * 2018-02-28 2019-08-29 Intuit Inc. Matching adopting users and contributing users for decentralized software localization

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6886038B1 (en) * 2000-10-24 2005-04-26 Microsoft Corporation System and method for restricting data transfers and managing software components of distributed computers
US6907395B1 (en) * 2000-10-24 2005-06-14 Microsoft Corporation System and method for designing a logical model of a distributed computer system and deploying physical resources according to the logical model
US7606898B1 (en) * 2000-10-24 2009-10-20 Microsoft Corporation System and method for distributed management of shared computers
US7188335B1 (en) * 2001-12-28 2007-03-06 Trilogy Development Group, Inc. Product configuration using configuration patterns
US7440902B2 (en) * 2002-04-12 2008-10-21 International Business Machines Corporation Service development tool and capabilities for facilitating management of service elements
US7302400B2 (en) * 2002-04-12 2007-11-27 International Business Machines Corporation System and method for the development and deployment of service elements
US7562022B2 (en) * 2002-04-12 2009-07-14 International Business Machines Corporation Packaging and distributing service elements
US7533026B2 (en) * 2002-04-12 2009-05-12 International Business Machines Corporation Facilitating management of service elements usable in providing information technology service offerings
CN1316351C (en) * 2002-09-30 2007-05-16 微软公司 System and method for making user interface elements known to an application and user
US7953779B1 (en) 2002-10-08 2011-05-31 Trilogy Development Group, Inc. Configuration representation and modeling using configuration spaces
US7689676B2 (en) 2003-03-06 2010-03-30 Microsoft Corporation Model-based policy application
US8122106B2 (en) * 2003-03-06 2012-02-21 Microsoft Corporation Integrating design, deployment, and management phases for systems
US7890543B2 (en) * 2003-03-06 2011-02-15 Microsoft Corporation Architecture for distributed computing system and automated design, deployment, and management of distributed applications
US20050050524A1 (en) * 2003-08-25 2005-03-03 Arm Limited Generating software test information
WO2005029382A2 (en) * 2003-09-19 2005-03-31 Lattix, Inc. Apparatus and method for managing design of a software system using dependency structure
GB2406661A (en) * 2003-09-30 2005-04-06 Toshiba Res Europ Ltd Configuring a computer apparatus subject to a constraint placed upon the system
US9652584B2 (en) * 2003-10-31 2017-05-16 The Boeing Company Aircraft design systems and methods
US7778422B2 (en) 2004-02-27 2010-08-17 Microsoft Corporation Security associations for devices
US20050246529A1 (en) * 2004-04-30 2005-11-03 Microsoft Corporation Isolated persistent identity storage for authentication of computing devies
US7817394B2 (en) * 2004-07-28 2010-10-19 Intel Corporation Systems, apparatus and methods capable of shelf management
US7966219B1 (en) * 2004-09-24 2011-06-21 Versata Development Group, Inc. System and method for integrated recommendations
US8590011B1 (en) * 2005-02-24 2013-11-19 Versata Development Group, Inc. Variable domain resource data security for data processing systems
US20060224541A1 (en) * 2005-03-21 2006-10-05 Ross Gerald H B Method and apparatus for pattern recognition for knowledge capture and customization
US8307336B1 (en) * 2005-03-30 2012-11-06 Oracle America, Inc. Mechanism for enabling a set of output from a functional component to be presented on different types of clients
US20060230382A1 (en) * 2005-04-12 2006-10-12 Moulckers Ingrid M System and method for managing a reusable set of business solution components
US7802144B2 (en) 2005-04-15 2010-09-21 Microsoft Corporation Model-based system monitoring
US8489728B2 (en) * 2005-04-15 2013-07-16 Microsoft Corporation Model-based system monitoring
US7797147B2 (en) * 2005-04-15 2010-09-14 Microsoft Corporation Model-based system monitoring
US20070016393A1 (en) * 2005-06-29 2007-01-18 Microsoft Corporation Model-based propagation of attributes
US8549513B2 (en) 2005-06-29 2013-10-01 Microsoft Corporation Model-based virtual system provisioning
US7895572B2 (en) * 2005-08-15 2011-02-22 Sap Aktiengesellschaft Systems and methods for enterprise software management
US7698695B2 (en) * 2005-08-31 2010-04-13 International Business Machines Corporation Search technique for design patterns in Java source code
US7941309B2 (en) 2005-11-02 2011-05-10 Microsoft Corporation Modeling IT operations/policies
US8201189B2 (en) 2005-12-30 2012-06-12 Sap Ag System and method for filtering components
US8271769B2 (en) 2005-12-30 2012-09-18 Sap Ag Dynamic adaptation of a configuration to a system environment
US7793087B2 (en) * 2005-12-30 2010-09-07 Sap Ag Configuration templates for different use cases for a system
US7797522B2 (en) * 2005-12-30 2010-09-14 Sap Ag Meta attributes of system configuration elements
US7694117B2 (en) * 2005-12-30 2010-04-06 Sap Ag Virtualized and adaptive configuration of a system
US8838750B2 (en) * 2005-12-30 2014-09-16 Sap Ag System and method for system information centralization
US8849894B2 (en) * 2005-12-30 2014-09-30 Sap Ag Method and system using parameterized configurations
US8843918B2 (en) 2005-12-30 2014-09-23 Sap Ag System and method for deployable templates
US20070156641A1 (en) * 2005-12-30 2007-07-05 Thomas Mueller System and method to provide system independent configuration references
US7870538B2 (en) * 2005-12-30 2011-01-11 Sap Ag Configuration inheritance in system configuration
US7954087B2 (en) * 2005-12-30 2011-05-31 Sap Ag Template integration
US7779389B2 (en) * 2005-12-30 2010-08-17 Sap Ag System and method for dynamic VM settings
US20070257715A1 (en) * 2005-12-30 2007-11-08 Semerdzhiev Krasimir P System and method for abstract configuration
US20070156715A1 (en) * 2005-12-30 2007-07-05 Thomas Mueller Tagged property files for system configurations
US9038023B2 (en) * 2005-12-30 2015-05-19 Sap Se Template-based configuration architecture
US7506145B2 (en) * 2005-12-30 2009-03-17 Sap Ag Calculated values in system configuration
US20070174781A1 (en) * 2006-01-25 2007-07-26 Catalog Data Solutions Parameter visualization
US7917889B2 (en) * 2006-06-19 2011-03-29 International Business Machines Corporation Data locations template based application-data association and its use for policy based management
US8074200B2 (en) * 2006-10-16 2011-12-06 International Business Machines Corporation Method and system for providing tooling instructions through parameterization as an aid for software application development
US8126693B2 (en) * 2008-01-15 2012-02-28 International Business Machines Corporation Method and system for modeling, validating and automatically resolving goals and dependencies between elements within a topology
US8126692B2 (en) * 2008-01-15 2012-02-28 International Business Machines Corporation Method and system for modeling, validating and automatically resolving goals and dependencies between elements within a topology
US8538889B2 (en) * 2008-06-25 2013-09-17 Microsoft Corporation Application hierarchy and state manipulation
US20090327301A1 (en) * 2008-06-26 2009-12-31 Microsoft Corporation Distributed Configuration Management Using Constitutional Documents
US7774442B2 (en) * 2008-06-26 2010-08-10 Microsoft Corporation Distributed configuration management using loosely-coupled action-style documents
US8578265B2 (en) * 2008-10-07 2013-11-05 Bigmachines, Inc. Methods and apparatus for generating a dynamic document
US9524506B2 (en) 2011-10-21 2016-12-20 Bigmachines, Inc. Methods and apparatus for maintaining business rules in a configuration system
US20100281429A1 (en) * 2009-04-30 2010-11-04 Bigmachines, Inc. Methods and apparatus for configuring a product using an array of configuration sets
US8812375B2 (en) 2011-10-07 2014-08-19 Ford Global Technologies, Llc Method and system for product configuration validation
US11676090B2 (en) 2011-11-29 2023-06-13 Model N, Inc. Enhanced multi-component object-based design, computation, and evaluation
US9098854B2 (en) 2013-03-15 2015-08-04 Ford Global Technologies, Llc Method and system for generating a global representation of a product definition
US9244808B2 (en) 2013-09-27 2016-01-26 International Business Machines Corporation Pattern oriented data collection and analysis
US9912751B2 (en) 2015-01-22 2018-03-06 International Business Machines Corporation Requesting storage performance models for a configuration pattern of storage resources to deploy at a client computing environment
US10506041B2 (en) 2015-01-22 2019-12-10 International Business Machines Corporation Providing information on published configuration patterns of storage resources to client systems in a network computing environment
US9917897B2 (en) * 2015-01-22 2018-03-13 International Business Machines Corporation Publishing configuration patterns for storage resources and storage performance models from client systems to share with client systems in a network computing environment
US10223654B2 (en) * 2015-03-23 2019-03-05 Accenture Global Services Limited Automated, accelerated prototype generation system
US10621154B2 (en) * 2015-12-31 2020-04-14 International Business Machines Corporation Identifying patterns of a set of software applications
US10318701B2 (en) 2016-01-19 2019-06-11 Ford Motor Company Resolving configuration conflicts using a multi-valued decision diagram

Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515524A (en) * 1993-03-29 1996-05-07 Trilogy Development Group Method and apparatus for configuring systems
US5812394A (en) * 1995-07-21 1998-09-22 Control Systems International Object-oriented computer program, system, and method for developing control schemes for facilities
US5825651A (en) * 1996-09-03 1998-10-20 Trilogy Development Group, Inc. Method and apparatus for maintaining and configuring systems
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
US5893106A (en) * 1997-07-11 1999-04-06 International Business Machines Corporation Object oriented server process framework with interdependent-object creation
US5937189A (en) * 1996-11-12 1999-08-10 International Business Machines Corporation Object oriented framework mechanism for determining configuration relations
US6002854A (en) * 1993-03-29 1999-12-14 Trilogy Developmetn Group, Inc. Method and apparatus for configuring systems
US6014637A (en) * 1997-04-30 2000-01-11 International Business Machines Corporation Object oriented framework mechanism for fulfillment requirements management
US6247049B1 (en) * 1997-04-15 2001-06-12 British Telecommunications Public Limited Company Design of computer networks
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6269473B1 (en) * 1998-03-23 2001-07-31 Evolve Software, Inc. Method and apparatus for the development of dynamically configurable software systems
US6298476B1 (en) * 1995-12-04 2001-10-02 International Business Machines Corporation Object oriented software build framework mechanism
US6404445B1 (en) * 1999-12-30 2002-06-11 Cybrant Corporation Method and system for modeling data
US6499036B1 (en) * 1998-08-12 2002-12-24 Bank Of America Corporation Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US6529948B1 (en) * 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US6618856B2 (en) * 1998-05-08 2003-09-09 Rockwell Automation Technologies, Inc. Simulation method and apparatus for use in enterprise controls
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6678882B1 (en) * 1999-06-30 2004-01-13 Qwest Communications International Inc. Collaborative model for software systems with synchronization submodel with merge feature, automatic conflict resolution and isolation of potential changes for reuse
US6880107B1 (en) * 1999-07-29 2005-04-12 International Business Machines Corporation Software configuration monitor
US6915307B1 (en) * 1998-04-15 2005-07-05 Inktomi Corporation High performance object cache
US6915253B1 (en) * 2000-09-13 2005-07-05 Fujitsu Limited Method for facilitating product configuration using components from a set
US6934931B2 (en) * 2000-04-05 2005-08-23 Pavilion Technologies, Inc. System and method for enterprise modeling, optimization and control
US6993743B2 (en) * 2000-06-03 2006-01-31 Sun Microsystems, Inc. Method and apparatus for developing enterprise applications using design patterns
US7003360B1 (en) * 2002-06-12 2006-02-21 Trilogy Development Group, Inc. System and method for product configuration using numerical clauses and inference procedures
US7103874B2 (en) * 2003-10-23 2006-09-05 Microsoft Corporation Model-based management of computer systems and distributed applications
US7124400B2 (en) * 2003-03-12 2006-10-17 Microsoft Corporation Extensible customization framework for a software system
US7137100B2 (en) * 2000-04-04 2006-11-14 Jose Iborra Automatic software production system
US7167865B1 (en) * 2003-06-30 2007-01-23 Mvalent, Inc. Collaborative environment for producing software products
US7188335B1 (en) * 2001-12-28 2007-03-06 Trilogy Development Group, Inc. Product configuration using configuration patterns
US7219327B1 (en) * 1999-07-01 2007-05-15 Affinity Internet, Inc. Extensible data model for use in an integrated platform for creating a distribution multiapplication online presence

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6115547A (en) 1993-03-29 2000-09-05 Trilogy Development Group, Inc. Flash configuration cache
US6157922A (en) 1997-10-24 2000-12-05 Trilogy Development Group, Inc. Method and apparatus for transparent backtracking

Patent Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6002854A (en) * 1993-03-29 1999-12-14 Trilogy Developmetn Group, Inc. Method and apparatus for configuring systems
US5708798A (en) * 1993-03-29 1998-01-13 Trilogy Development Group Method and apparatus for configuring systems
US5515524A (en) * 1993-03-29 1996-05-07 Trilogy Development Group Method and apparatus for configuring systems
US5812394A (en) * 1995-07-21 1998-09-22 Control Systems International Object-oriented computer program, system, and method for developing control schemes for facilities
US6298476B1 (en) * 1995-12-04 2001-10-02 International Business Machines Corporation Object oriented software build framework mechanism
US5825651A (en) * 1996-09-03 1998-10-20 Trilogy Development Group, Inc. Method and apparatus for maintaining and configuring systems
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
US6300948B1 (en) * 1996-09-17 2001-10-09 Scott D. Geller Methods and systems for user interfaces and constraint handling in configuration software
US5937189A (en) * 1996-11-12 1999-08-10 International Business Machines Corporation Object oriented framework mechanism for determining configuration relations
US6247049B1 (en) * 1997-04-15 2001-06-12 British Telecommunications Public Limited Company Design of computer networks
US6014637A (en) * 1997-04-30 2000-01-11 International Business Machines Corporation Object oriented framework mechanism for fulfillment requirements management
US5893106A (en) * 1997-07-11 1999-04-06 International Business Machines Corporation Object oriented server process framework with interdependent-object creation
US6269473B1 (en) * 1998-03-23 2001-07-31 Evolve Software, Inc. Method and apparatus for the development of dynamically configurable software systems
US6915307B1 (en) * 1998-04-15 2005-07-05 Inktomi Corporation High performance object cache
US6618856B2 (en) * 1998-05-08 2003-09-09 Rockwell Automation Technologies, Inc. Simulation method and apparatus for use in enterprise controls
US6499036B1 (en) * 1998-08-12 2002-12-24 Bank Of America Corporation Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US6678882B1 (en) * 1999-06-30 2004-01-13 Qwest Communications International Inc. Collaborative model for software systems with synchronization submodel with merge feature, automatic conflict resolution and isolation of potential changes for reuse
US7219327B1 (en) * 1999-07-01 2007-05-15 Affinity Internet, Inc. Extensible data model for use in an integrated platform for creating a distribution multiapplication online presence
US6880107B1 (en) * 1999-07-29 2005-04-12 International Business Machines Corporation Software configuration monitor
US6529948B1 (en) * 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US6662357B1 (en) * 1999-08-31 2003-12-09 Accenture Llp Managing information in an integrated development architecture framework
US6256773B1 (en) * 1999-08-31 2001-07-03 Accenture Llp System, method and article of manufacture for configuration management in a development architecture framework
US6404445B1 (en) * 1999-12-30 2002-06-11 Cybrant Corporation Method and system for modeling data
US7137100B2 (en) * 2000-04-04 2006-11-14 Jose Iborra Automatic software production system
US6934931B2 (en) * 2000-04-05 2005-08-23 Pavilion Technologies, Inc. System and method for enterprise modeling, optimization and control
US6993743B2 (en) * 2000-06-03 2006-01-31 Sun Microsystems, Inc. Method and apparatus for developing enterprise applications using design patterns
US6915253B1 (en) * 2000-09-13 2005-07-05 Fujitsu Limited Method for facilitating product configuration using components from a set
US7188335B1 (en) * 2001-12-28 2007-03-06 Trilogy Development Group, Inc. Product configuration using configuration patterns
US7003360B1 (en) * 2002-06-12 2006-02-21 Trilogy Development Group, Inc. System and method for product configuration using numerical clauses and inference procedures
US7124400B2 (en) * 2003-03-12 2006-10-17 Microsoft Corporation Extensible customization framework for a software system
US7167865B1 (en) * 2003-06-30 2007-01-23 Mvalent, Inc. Collaborative environment for producing software products
US7103874B2 (en) * 2003-10-23 2006-09-05 Microsoft Corporation Model-based management of computer systems and distributed applications

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090144702A1 (en) * 2004-06-30 2009-06-04 International Business Machines Corporation System And Program Product for Determining Java Software Code Plagiarism and Infringement
US7975256B2 (en) * 2004-06-30 2011-07-05 International Business Machines Corporation Optimizing application performance through data mining
US20060005177A1 (en) * 2004-06-30 2006-01-05 International Business Machines Corp. Method, system and program product for optimizing java application performance through data mining
US20080098355A1 (en) * 2006-09-29 2008-04-24 Sap Ag Integrated configuration of cross organizational business processes
US8042090B2 (en) * 2006-09-29 2011-10-18 Sap Ag Integrated configuration of cross organizational business processes
US20100049857A1 (en) * 2007-04-13 2010-02-25 Scott Allan Libert System software productization framework
US8245020B1 (en) * 2008-05-13 2012-08-14 Selectica, Inc. Creating a partial instance of component in response to user specifying a value for a dynamic attribute of a selected component
US9383978B2 (en) * 2010-03-19 2016-07-05 Samsung Electronics Co., Ltd. Apparatus and method for on-demand optimization of applications
US20110231813A1 (en) * 2010-03-19 2011-09-22 Seo Sun Ae Apparatus and method for on-demand optimization of applications
US8965831B2 (en) 2012-07-27 2015-02-24 Selectica, Inc. System, method, and software program product for enabling users to create and use rule patterns to generate custom product-configuration rules
US20160124718A1 (en) * 2014-11-05 2016-05-05 Oracle International Corporation Context-based generation of memory layouts in software programs
US9552192B2 (en) * 2014-11-05 2017-01-24 Oracle International Corporation Context-based generation of memory layouts in software programs
US10275154B2 (en) 2014-11-05 2019-04-30 Oracle International Corporation Building memory layouts in software programs
US10353793B2 (en) 2014-11-05 2019-07-16 Oracle International Corporation Identifying improvements to memory usage of software programs
US20190265992A1 (en) * 2018-02-28 2019-08-29 Intuit Inc. Matching adopting users and contributing users for decentralized software localization
US10664294B2 (en) * 2018-02-28 2020-05-26 Intuit Inc. Matching adopting users and contributing users for decentralized software localization

Also Published As

Publication number Publication date
US7188335B1 (en) 2007-03-06

Similar Documents

Publication Publication Date Title
US7188335B1 (en) Product configuration using configuration patterns
US8776009B2 (en) Method and system for task modeling of mobile phone applications
Puhlmann et al. Variability mechanisms for process models
CN100580622C (en) Telecommunication region modeling tool based on unified modeling language and modeling method
CN1820514B (en) System architecture, method and computer program product for managing telecommunication networks
CN105260203B (en) A kind of Hadoop deployment and collocation method based on model
WO2006099046A2 (en) Automated interface-specification generation for enterprise architectures
Dutta et al. A data set for quantitative motion analysis
Pascalau et al. On maintaining consistency of process model variants
US8832641B2 (en) Model-operative pattern representation and operational enablement using declarative componential-driven domain-specific programming language
CN101495987B (en) Node-to-node communication pipelines
Cirilo et al. Integrating component and product lines technologies
Hutchinson et al. A service model for component-based development
US20070002751A1 (en) Model-driven service creation and management
Strassner et al. TMF white paper on NGOSS and MDA
Eilam et al. Model-based automation of service deployment in a constrained environment
Cornily et al. Specifying distributed object applications using the reference model for Open Distributed Processing and the Unified Modeling Language
Balasubramanian et al. Weaving deployment aspects into domain-specific models
Atoui et al. Configurable deployment descriptor model in NFV
Bouhdadi et al. Meta-modelling syntax and semantics of structural concepts for open networked enterprises
Carvallo et al. Requirements engineering for COTS-based software systems
Stojanovic et al. Integration of Component-Based Development Concepts and RM-ODP Viewpoints.
Bochmann et al. Formal Description of Network Management Issues
Beugnard et al. Towards context-aware components
Garlan Evolution Styles: Formal foundations and tool support for software architecture evolution

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION