Field of the Invention
The present invention relates to the field of information service architectural design and, more particularly, to a solution that automatically recommends design assets when making architectural design decisions for information services.
Description of the Related Art
The use of service-oriented architecture (SOA) environments and information services is fast becoming the preferred implementation for enterprise systems. A popular method for creating the architectural design models used to implement information services is the use of application patterns. An application pattern represents a repeatable solution to a problem in a particular context. For example, the preferred data source pattern is applicable when an information service requires data consistency.
As businesses expand their enterprise capabilities, more information services are added to the network to accommodate the expansion. The design and development of information services promotes the reuse of application patterns for addressing the same non-functional requirement in a similar context. However, the architects who gather non-functional requirements and make architectural decisions often do not have a comprehensive list of all the pattern assets that are available for use. Thus, the design of information services depends upon an architect's awareness of available assets to use when designing the information service.
Further, some assets require that an architect understand how to install the asset into a software application in order to use the asset. For example, a pattern implementation needs to be installed within a modeling tool, such as RATIONAL SOFTWARE ARCHITECT, in ordered to be used in design activities.
What is needed is a solution that automatically recommends design assets for architects when designing information services. That is, the solution would automatically query existing asset repositories for assets that address the non-functional requirement that a solution architect is attempting to satisfy. Ideally, such a solution would also document the architectural decisions made in order to provide usage metrics.
The present invention discloses a solution for automatically suggesting design assets when making architectural decisions for information services in a service-oriented architecture (SOA). This solution can utilize an asset advisory tool that can present a user with a list of recommended design assets for a selected non-functional requirement. The advisory tool can also present a user with a list of assets that are available for use from an asset repository. When an asset is selected for use, the advisory tool can automatically document the asset used for to satisfy the non-functional requirement in a decision log. The decision log can then be used to determine a multitude of usage metrics.
The present invention can be implemented in accordance with numerous aspects consistent with material presented herein. For example, one aspect of the present invention can include a system that provides automated guidance for making architectural decisions when designing information services in a service-oriented architecture (SOA). Such a system can include a requirements manager, a reusable asset repository, and an asset advisory tool. The requirements manager can be configured to capture non-functional requirements for information services. The reusable asset repository can be configured to store design assets. The design assets can be stored according to a unique data model that associates each design asset with a non-functional requirement. The asset advisory tool can be configured to determine a list of recommended design assets for a user-selected non-functional requirement and document the architectural decision made from the list of recommended design assets.
Another aspect of the present invention can include a method for automatically recommending design assets for information service architectural design decisions. In this method, an asset advisory tool can monitor a requirements manager for the addition of non-functional requirements. When a non-functional requirement is added, the asset advisory tool can automatically query a reusable asset repository for corresponding design assets. The advisory tool can present the results of the query as a list of recommended design assets in a user interface. The advisory tool can then receive a user-selection of a design asset from the list. The selected design asset can be retrieved from the reusable asset repository. The advisory tool can then provide access to the design asset.
Still another aspect of the present invention can include an asset advisory tool. The asset advisory tool can include a user interface and a decision log. The user interface can be configured to accept and execute user-selected actions. The decision log can be configured to store data that describes the context of an architectural decision.
It should be noted that various aspects of the invention can be implemented as a program for controlling computing equipment to implement the functions described herein, or a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, any other recording medium, or can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space.
There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
The requirements manager 140 can be a software application designed to capture and store design requirements. Non-functional requirements 107 can be stored in a requirements data store 145. The requirements manager 140 can be a commercially-available system, such as RATIONAL REQUISITE PRO, that can be implemented independently of the advisory tool 110.
The advisory tool 110 can be a software application that can monitor the activities and/or contents of the requirements manager 140 in order to produce a list of recommended design assets 150 when a non-functional requirement 107 is input. In order to generate the list of recommended design assets 150, the advisory tool 110 can query a reusable asset repository 130 to determine which design assets 135 pertain to the non-functional requirement 107. In an alternate embodiment, the advisory tool 110 can monitor multiple requirements managers 140 and access multiple reusable asset repositories 130.
The reusable asset repository 130 can be a data store configured to contain a multitude of design assets 135. Design assets 135 can encompass a variety of items, including, but not limited to, pattern recipes, pattern specifications, pattern implementations, data models, design manuals, and the like.
The design assets 135 can be stored within the reusable asset repository 130 using a unique data model containing fields that relate the design asset 135 with a particular non-functional requirement 107, software application (not shown), and/or software application version. For example, the preferred data source pattern asset 135 can be stored with a data attribute associating it with a consistency non-functional requirement 107.
Further, multiple instances of a design asset 135 can exist in the repository 130 where each instance corresponds to a different software application. For example, two pattern implementations can exist for the preferred data source pattern—one meant for use with RATIONAL SOFTWARE ARCHITECT version 7.0 and the other for use with WEBSPHERE BUSINESS MODELER.
The advisory tool 110 can include a user interface 115 and a data store 120 containing decision logs 123. The advisory tool 110 can be implemented as a plug-in component that utilizes communication standards that support cross-platform interoperability and/or as a light-weight Web application. For example, the advisory tool 110 can be written as an ECLIPSE environment plug-in that utilizes an extensible markup language (XML) schema, which can then interface with other software applications that utilize the ECLIPSE environment as well as applications that support XML transactions.
The user interface 115 can be the means by which the advisory tool 110 interacts with the solution architect 105. The user interface 115 can display the list of recommended design assets 150 to the solution architect 105 as well as receive input from the architect 105.
The decision logs 123 can be the means by which the advisory tool 110 can automatically document architectural design decisions. A decision log 123 can include information pertaining to the non-functional requirement 107 being addressed and the design assets 135 used to satisfy the requirement 107. In another embodiment, the decision log 123 can be stored in a remotely-located data store (not shown).
It should be noted that the automatic documentation of requirements 107 satisfaction with specific design assets 135 is a feature currently unavailable in conventional software tools used in the design of information services in a service-oriented architecture (SOA). By capturing the design assets 135 used to satisfy non-functional requirements 107 automatically and electronically, the data of the decision log 123 can be processed to determine a variety of valuable information, such as decision consistency, usage metrics, and unsatisfied requirements.
Additionally, when a solution architect 105 selects a design asset 135 for use from the list of recommended design assets 150, the advisory tool 110 can retrieve the selected design asset 135 from the reusable asset repository 130 and make the design asset 135 available to the solution architect 105. The advisory tool 100 can make the selected design asset 135 available to the solution architect 105 in a variety of ways, depending on the type of design asset 135, how the design asset 135 is stored, and the applications available to the solution architect 105.
For example, if the solution architect 105 chooses to use the preferred data source pattern 135 to address the non-functional requirement 107, then the advisory tool 110 can correlate the software applications available to the solution architect 105 with the software applications necessary to utilize the preferred data source pattern assets 135 in the repository 130.
The advisory tool 110 can then use this correlation to generate a relevance weighting for each asset 135 to include in the display of preferred data source pattern assets 135. This can allow the solution architect 105 to make a more informed asset 135 selection. Further, in cases where a selected design asset 135 requires an installation to be usable by a software application, the advisory tool 110 can automatically initiate the installation for the solution architect 105, thereby providing seamless access to the asset 135.
It should be noted that the components 110, 130, and 140 of system 100 can be communicatively linked via one or more secure and/or unsecured networks (not shown). Such networks (not shown) can include any hardware/software/and firmware necessary to convey data encoded within carrier waves. Data can be contained within analog or digital signals and conveyed though data or voice channels. These networks (not shown) can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. Additionally, these networks (not shown) can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data network, such as the Internet. Further, such networks (not shown) can also include circuit-based communication components and mobile communication components, such as telephony switches, modems, cellular communication towers, and the like. The networks (not shown) can include line based and/or wireless communication pathways.
As used herein, presented data stores, including stores 120, 130, and 145 can be a physical or virtual storage space configured to store digital information. Data stores 120, 130, and 145 can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. Data stores 120, 130, and 145 can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within data stores 120, 130, and 145 in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, data stores 120, 130, and/or 145 can utilize one or more encryption mechanisms to protect stored information from unauthorized access.
The data model 200 can be written in a formal modeling language, such as the Unified Modeling Language (UML) class diagram used in this example. The data model 200 can consist of seven classes: DesignAsset 205, PatternAsset 210, PatternPublication 215, FeatureDesignSpecification 220, PatternSupportingMedia 225, PatternSpecification 230, and PatternImplementation 235.
The DesignAsset class 205 can be the root class and can encompass different types of design assets. This example data model 200 focuses on pattern assets, as shown by the PatternAsset class 210.
The classes 205, 210, 215, 220, 225, 230, and 235, in following with the standard format of UML class diagrams, can each include a set of data attributes and/or methods. Of particular note is the attribute set 212 belonging to the PatternAsset class 210. As shown in this example, the set of attributes 212 can include a patternName and nonFunctionalRequirement. Through the use of these attributes 212, a PatternAsset 210 can be related to a specific non-functional requirement.
Because these attributes 212 are contained in a class 210 that is relatively high in the data model 200 hierarchy, the time necessary to query this data based on a pattern name or non-functional requirement, such as those that would be performed by an advisory tool, can be decreased. That is, the advisory tool would not need to traverse far into the data model 200 in order to find these attributes 212.
Data model 200 can be read as follows. A DesignAsset 205 can be a PatternAsset 210. A PatternAsset 210 can include many PatternPublications 215, a PatternSpecification 230, a FeatureDesignSpecification 220, and/or multiple PatternImplementations 235.
A PatternPublication 215 can have many PatternSupportingMedia 225 and/or a PatternSpecification 230. For example, a design manual can be available as a WORD document, a PDF document, and a FLASH document.
A FeatureDesignSpecification 220 can include a PatternPublication 215 and can have multiple PatternImplementations 235. A PatternSpecification 230 can also have multiple PatternImplementations 235.
The PatternImplementation 235 can include attributes 237 that indicate the name of the software application and/or the version of the software application that can be used to access the PatternImplementation 235. This structure can allow multiple PatternImplementations 235 to exist within the repository for various applications and/or application versions.
In this example, collection 300 can include interfaces presenting a requirements view 305, an asset view 320, and an asset retrieval 330. The requirements view 305 can present a solution architect with a list of non-functional requirements 310 and associated details 315. The non-functional requirements 310 and details 315 presented in the requirements view 305 can be obtained from a requirements repository, such as the requirements manager 140 of system 100.
From the requirements view 305, a solution architect can select a non-functional requirement 310 of interest or that pertains to the particular information service being designed.
The asset view 320 can present a listing of assets 325 that pertain to the specific non-functional requirement, such as the list of recommended design assets 150 of system 100. Further, the asset view 320 can be presented as the result of a user-selection of a non-functional requirement 310 from the requirements view 305.
The assets 325 listed in the asset view 320 can be the results of querying one or more reusable asset repositories that contain the listed design assets 325. The information displayed in the asset list 325 can correspond to the patternName attribute of the PatternAsset class 210 of the example data model 200. A solution architect can select a listed asset 325 to use to satisfy the non-functional requirement.
The selection of an asset 325 in the asset view 320 can result in the display of the asset retrieval interface 330. The asset retrieval interface 330 can display the specific asset items available for use for the asset selected from the asset view 320. Information displayed in the asset retrieval interface 330 can include the quantity of assets retrieved 335, the file path 340 of the asset, the name of the reusable asset repository 345 where the asset can be found, and a relevance weighting 350.
The quantity of assets retrieved 335 can identify the total number of matching assets found in reusable asset repositories. It should be noted that this quantity 335 can include multiple instances of the same asset that are for different modeling tools or in different formats.
The file path 340 can identify the file system location of a specific asset. The repository name 345 can indicate the specific reusable asset repository where the asset can be found.
The relevance weighting 350 can represent the degree to which the asset is usable to the solution architect. The advisory tool can calculate the relevance weighting 350 using an algorithm and values for a variety of factors that influence usability. For example, the relevance weighting 350 of an asset can be significantly decreased if the solution architect does not have access to the application necessary to use the asset.
Method 400 can begin with step 405 where a solution architect inputs a non-functional requirement into a requirements manager. An advisory tool can become aware of the added non-functional requirement in step 410.
In step 415, the advisory tool can query an asset repository for assets that correspond to the non-functional requirement. The advisory tool can present a list of recommended assets to the solution architect in step 420. The list presented in step 420 can consist of the names or titles of assets that can be used to satisfy the non-functional requirement.
In step 425, the solution architect can determine if the presented list of recommended assets requires refinement. When the solution architect decides to refine the list of recommended assets, flow can proceed to step 430 where the solution architect can input additional information into the advisory tool as the basis of refinement.
In step 435, the advisory tool can adjust the list of recommended assets based on the input of step 430. The solution architect can optionally access information related to a listed asset in order to determine the asset's applicability in step 440.
After the execution of step 440, flow returns to step 425 where the solution architect can reassess the state of the adjusted list of recommended assets. Method 400 can continue to repeat steps 425 through 440 until the solution architect no longer wishes to refine the list of recommended assets.
When the refinement of the list of recommended assets is no longer necessary, flow can proceed to step 445 where the solution architect can select an asset from the list. In step 450, the advisory tool can query the asset repository for all available asset types that correspond to the selected asset. For example, a selection of the preferred data source pattern can return a list containing a pattern implementation and a pattern specification.
This list of available assets can be presented to the solution architect in step 455. In step 460, the solution architect can select a specific asset from the list presented in step 455. The advisory tool can retrieve the selected asset from the asset repository in step 465.
Optionally, the advisory tool can automatically install the retrieved asset into its corresponding application in step 470. In step 475, the advisory tool can automatically log the architectural decision that was made by the solution architect.
The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
6256773 | Bowman-Amuah | Jul 2001 | B1 |
6539396 | Bowman-Amuah | Mar 2003 | B1 |
6658644 | Bishop et al. | Dec 2003 | B1 |
6799174 | Chipman et al. | Sep 2004 | B2 |
7080064 | Sundaresan | Jul 2006 | B2 |
7099859 | Sundaresan | Aug 2006 | B2 |
7103871 | Kirkpatrick et al. | Sep 2006 | B1 |
7225241 | Yada | May 2007 | B2 |
7318055 | Britton et al. | Jan 2008 | B2 |
7366706 | Chang et al. | Apr 2008 | B2 |
7412457 | Saracco et al. | Aug 2008 | B2 |
7483973 | An et al. | Jan 2009 | B2 |
7526501 | Albahari et al. | Apr 2009 | B2 |
7546295 | Brave et al. | Jun 2009 | B2 |
1260565 | Coldicott et al. | Oct 2009 | A1 |
7761406 | Harken | Jul 2010 | B2 |
7890517 | Angelo et al. | Feb 2011 | B2 |
7979840 | Zhang et al. | Jul 2011 | B2 |
20020069102 | Vellante et al. | Jun 2002 | A1 |
20020073106 | Parker et al. | Jun 2002 | A1 |
20020194053 | Barrett et al. | Dec 2002 | A1 |
20030009740 | Lan | Jan 2003 | A1 |
20030233631 | Curry et al. | Dec 2003 | A1 |
20040172612 | Kasravi et al. | Sep 2004 | A1 |
20040193476 | Aerdts | Sep 2004 | A1 |
20050050311 | Joseph et al. | Mar 2005 | A1 |
20050050549 | Joseph et al. | Mar 2005 | A1 |
20050138113 | Brendle et al. | Jun 2005 | A1 |
20050166178 | Masticola et al. | Jul 2005 | A1 |
20050262191 | Mamou et al. | Nov 2005 | A1 |
20050278202 | Broomhall et al. | Dec 2005 | A1 |
20060015489 | Probst et al. | Jan 2006 | A1 |
20060047810 | Herzog et al. | Mar 2006 | A1 |
20060070083 | Brunswig et al. | Mar 2006 | A1 |
20060174222 | Thonse et al. | Aug 2006 | A1 |
20060229896 | Rosen et al. | Oct 2006 | A1 |
20060236307 | Debruin et al. | Oct 2006 | A1 |
20060241931 | Abu el Ata et al. | Oct 2006 | A1 |
20070073663 | McVeigh et al. | Mar 2007 | A1 |
20070112712 | Flinn et al. | May 2007 | A1 |
20070239768 | Quinn-Jacobs | Oct 2007 | A1 |
20070261027 | Dhanakshirur et al. | Nov 2007 | A1 |
20070271277 | Ivan et al. | Nov 2007 | A1 |
20080052314 | Batabyal | Feb 2008 | A1 |
20080059630 | Sattler et al. | Mar 2008 | A1 |
20080091448 | Niheu et al. | Apr 2008 | A1 |
20080114700 | Moore et al. | May 2008 | A1 |
20080126397 | Alexander et al. | May 2008 | A1 |
20080127047 | Zhang et al. | May 2008 | A1 |
20080133558 | Carlson et al. | Jun 2008 | A1 |
20080134137 | Petersen | Jun 2008 | A1 |
20080178147 | Meliksetain et al. | Jul 2008 | A1 |
20080215358 | Goldszmidt et al. | Sep 2008 | A1 |
20080215400 | Ban et al. | Sep 2008 | A1 |
20080229195 | Brauel et al. | Sep 2008 | A1 |
20080270372 | Hsu et al. | Oct 2008 | A1 |
20080288944 | Coqueret et al. | Nov 2008 | A1 |
20090064087 | Isom | Mar 2009 | A1 |
20090077043 | Chang et al. | Mar 2009 | A1 |
20090089078 | Bursey | Apr 2009 | A1 |
20090109225 | Srivastava et al. | Apr 2009 | A1 |
20090112908 | Wintel et al. | Apr 2009 | A1 |
20090132211 | Lane et al. | May 2009 | A1 |
20090138293 | Lane et al. | May 2009 | A1 |
20090158237 | Zhang et al. | Jun 2009 | A1 |
20090182610 | Palanisamy et al. | Jul 2009 | A1 |
20090182750 | Keyes et al. | Jul 2009 | A1 |
20090193057 | Maes | Jul 2009 | A1 |
20090193432 | McKegney et al. | Jul 2009 | A1 |
20090201917 | Maes et al. | Aug 2009 | A1 |
20090204467 | Rubio et al. | Aug 2009 | A1 |
20090210390 | Lane | Aug 2009 | A1 |
20100082387 | Cao et al. | Apr 2010 | A1 |
20100106656 | Sheth et al. | Apr 2010 | A1 |
20100161629 | Palanisamy et al. | Jun 2010 | A1 |
20110035391 | Werner et al. | Feb 2011 | A1 |
20110153292 | Lane et al. | Jun 2011 | A1 |
20110153293 | Coldicott et al. | Jun 2011 | A1 |
20110153608 | Lane et al. | Jun 2011 | A1 |
20110153610 | Carrato et al. | Jun 2011 | A1 |
20110153767 | Coldicott et al. | Jun 2011 | A1 |
20110238610 | Lee et al. | Sep 2011 | A1 |
Number | Date | Country |
---|---|---|
2007113164 | Oct 2007 | WO |
Entry |
---|
U.S. Appl. No. 12/605,660, filed Oct. 26, 2009, Coldicott et al. |
Chen, D-W. et al.; “A P2P based Web service discovery mechanism with bounding deployment and publication”, Chinese Journal of Computers; vol. 28; No. 4; pp. 615-626; Apr. 2005. |
Lee, J. et al.; “Semantic and Dynamic Web Service of SOA based Smart Robots using Web 2.0 Open API”, 2008; Sixth International Conference on Software Engineering, Research, Management, and Application; pp. 255-260. |
Demirkan, H. et al.; “Service-oriented technology and management: Perspectives on research and practice for the coming decade”; Electronic Commerce Research and Applications vol. 7 Issue 4; Jan. 2008; pp. 356-376. |
Zdun, U. et al.; “Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives”; ACM Transactions on the Web; vol. 1 No. 3 Article 14; Sep. 2007; 44 pages. |
Simoes, B. et al.; “Enterprise-level Architecture for Interactive Web-based 3D Visualization of Geo-referenced Repositories”; Association for Computing Machinery Inc. 978-1-60558-432-4/09/0006; Jun. 2009; pp. 147-154. |
Kanakalata et al; Performance Opitimization of SOA based AJAX Application; 2009; pp. 89-93. |
Annett et al.; “Building Highly-Interactive, Data-Intensive, REST Applications: The Invenio Experience”; 2008; pp. 1-15. |
Arnold et al.; “Automatic Realization of SOA Deployment Patterns in Distributed Environments”; ICSOC 2008; LNCS 5364; 2008; pp. 162-179. |
Justin Kelleher, “A Reusable Traceability Framework Using Patterns”, University of Cape Town, ACM Digital Library, 2005, pp. 50-55. |
Sharples et al., “The Design and Implementation of a Mobile Learning Resource”, Educational Technology Research Group, University of Birmingham, ACM Digital Library, 2002, pp. 1-23. |
Min Luo, “Tutorial 1: Common Business Components and Services Toward More Agile and Flexible Industry Solutions and Assets”, 2008 IEEE Congress on Services Part II, pp. 11-12. |
Ying Huang et al., “A Stochastic Service Composition Model for Business Integration”, Proceeds of the International Conference on Next Generation Web Services Practices, 2005 IEEE Computer Society, pp. 1-8. |
Pham et al., “Analysis of Visualisation Requirements for Fuzzy Systems”, 2003 ACM, pp. 181-187. |
“System and Method for Distributed Web Service Adaptation using Aspect oriented Programming”, IBM Technical Disclosure Bulletin, Sep. 15, 2008, pp. 1-3. |
Baum et al., “Mapping Requirements to Reusable Components using Design Spaces”, 2000, Proceedings 4th International Conference on Requirements Engineering, pp. 159-167. |
Hsiung et al., “VERTAF: An Application Framework for the Design and Verification of Embedded Real-Time Software”, IEEE Transactions on Software Engineering, vol. 30, No. 10, Oct. 2004, pp. 656-674. |
Robinson et al., “Finding Reusable UML Sequence Diagrams Automatically”, IEE Software, 2004, pp. 60-67. |
Jin et al., “Automated Requirements Elicitation: Combining a Model-Driven Approach with Concept Reuse”, International Journal of Software Engineering and Knowledge Engineering, vol. 13, No. 1, 2003, pp. 53-82. |
Number | Date | Country | |
---|---|---|---|
20090138293 A1 | May 2009 | US |