Real-time embedded software respository with attribute searching apparatus and method5778368Abstract The Real-Time Embedded Software Repository Apparatus fully characterizes, evaluates, and reuses real-time embedded software that is placed or stored in a repository database. The Repository System comprises at least one Repository Client and at least one Repository Server and utilizes simulation and translational techniques to allow Real Time Embedded Software (RTES) to be re-used, played, and evaluated on various desktop development environments or target operating environments. The Repository System organizes and processes Repository files as Repository Units which may comprise Software Source Files and Test Software. Repository Units also contain Attachments that provide current and historic information to static files that are stored in the Repository. The Repository Units are further characterized using analysis tools (software analysis) which allow the user to associate fixed and user defined Attributes to the RTES. A real-time embedded component (Component) provides a clear and well defined software interface to function at a high level of interaction with the RTES. Templates for both searching and displaying information in a multimedia format are also provided. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
MXP Software Language Creator
Size Group
______________________________________
Quality
Target Creation Project
Makefile
Cost
Date
______________________________________
Preferably, other System defined Attributes that are either required by the Repository System or are automatically assigned by the Repository Server include: Repository Unit Name; Repository Unit Creator; Revision Number; Original Repository Unit File Name; Repository Unit Type (e.g. Component, Framework, etc.); Repository Unit Password (if required); Repository Unit Text Description; Repository Unit Key Words; Parent Repository Unit List (this facilitates the hierarchical structure of Repository Units); Child Repository Unit list (this facilitates the hierarchical structure of Repository Units); and Peer Repository Unit List (this facilitates the relational structure of Repository Units). In addition to Repository defined Attributes, the user or System Administrator also assigns Attributes 23 to aid in providing stronger application specific characterization of the Repository Units. Some examples of user or System Administrator assigned Attributes include: E-mail address of creator; mailing address of creator, development costs; list price of Repository Units; processor type; required MIPS; and required memory. It is important to recognize that the above Repository System defined and user or System Administrator assigned Attributes are not intended to be exhaustive listing, and as such, a person of ordinary skill in the present art will realize that other attributes are envisioned with the present invention. A detailed description of the search and downloading of Repository Units based on Attribute searching follows. Repository Server A Repository Server is a multi-user server that provides access to reusable software to an internetworked user community. The Repository Server utilizes a commercial web server/browser product such as Netscapes or other software with similar properties to provide platform independent access to the Repository. Each Repository Server is independently searchable. The Repository Servers further allow Repository Units to be searched, played, checked-in, checked-out, or purchased by a Repository user. Repository Clients and Repository Stations are supported by the Repository Servers. The Repository Servers support groups of Repository users who share common Repository facilities. A Repository Station has Client Repository capabilities and also supports a self-contained single user Repository not accessible to others. FIG. 2 illustrates a system level block diagram which represents a logical hierarchy of inter-networked Repositories, i.e., storage areas, which contain Repository Units that are valuable to developers of RTES. The Repository Servers 7, 10, and 12 are multi-user servers that provide access to reusable software to an internetworked user community. The Repository Servers 7, 10, and 12 are accessed by Repository Clients 8 and 9 and Repository Station 11. The Repository Clients 8 and 9 and Repository Station 11 access the appropriate Repository databases where the Repository Units meeting the requirements of a particular search reside. Several Repository Clients and Repository Stations can simultaneously access a number of different Repositories. Thus, the Repository System supports multiple users, using Repository Clients simultaneously logged into multiple Repository Servers. The Repository Clients can be located anywhere in the internetwork, such as a Local Area Network (LAN), on distributed networked LANs, on distributed LANs across the Internet, on distributed Wide Area Networks (WAN), on distributed Metropolitan Area Networks (MAN), or any combination of the above. In the preferred embodiment, the Repository System utilizes the TCP/IP protocol suite for networking support and services. The preferred embodiment also utilizes Internet Web Technology for communication between Repository Servers, Repository Clients, and Repository Stations. The Repository Servers 7, 10, and 12 comprise the following components in the preferred embodiment: Web Server Package (protocols HTTP/TCP/IP, FTP/TCP/IP, etc.) Windows NT Version 3.51 or greater Security Package Repository Entry and Introduction Web Pages Repository CGI/server API Programs for Repository Access and/or Administration Repository Search Engine FTP Server Analysis Tools to Annotate Checked-in Repository Units Hard Drives for Storage of Repository Units and Repository Meta-data Networked Access Software Database Program Utilization (SQL) Compiler/Linker/Loader Tools for building check-in source code Repository Units Other alternative embodiments also clearly exist. For example, the present invention may also be implemented on UNIX-based DEC, HP platforms or others that may occur. The networked access software allows the user to access and search a multitude of off-site or local on-site Repository Servers simultaneously. However, it is possible for a user with the appropriate permission to search multiple Repositories or to be restricted to only certain Repositories. Access is restricted generally without the proper login name and password identifier. The Repository Search Engine also aids the software engineer in finding Components, Frameworks, and other objects on the distributed Repository Servers. The Repository Servers 7, 10, and 12 are completely contained within a company's local internetwork or distributed across a global Internet. Users with appropriate access permission have the ability to access all known Repositories within the system from a single entry point and are searchable by a single user with one search command. The Repository Server is capable of supporting numerous user names and numerous distributed Repositories simultaneously. In alternate embodiments, all Repository Servers in the network system have rules that allow them to access and search any other Repository database or deny access to the search as required. The Repository databases may also be encrypted so that the Repository Clients are denied access to the Repository databases via encryption or password identifiers. Shadow Server 13 contains an index of Shadow Repository 13a of the contents of Repository Server 12 and is intended to provide searching capabilities only. Shadow Server 13 performs the search of the Shadow Repository 13a that Repository Server 12 would perform if it was not "bottle-necked." Logic in the Repository Server 12 redirects the request for the HTML document that contains the searching program to the Shadow Server 13. The Shadow Server 13 then executes the appropriate search utilizing index files associated with the Repository Units. Repository Server 12 keeps its Shadow Server 13 and Shadow Repository 13a current by downloading its index files upon any change, or on a specific schedule. In alternate embodiments a Shadow Server and Shadow Repository exists on any Repository Server or Repository, respectively, in the Repository System. Referring to FIG. 3 the user typically accesses the Repository Server through a Repository interface preferably known as a login page 14. The login page 14 is preferably established on a user interface Repository System based on web pages and a windows or compatible program. It is also envisioned that login may occur without the aid of web technology. In the preferred embodiment the web pages are utilized by the Repository Server 7. The web pages are dynamically created and are completely interactive with multimedia capabilities. The user's desktop utilizes a Windows or compatible program for viewing any downloaded information received from the Repository Server 7. The user uses the Windows program for such purposes as Repository Unit Packaging, Application Playing, and Repository Unit Un-packaging. The Repository login page 14 comprises a login name 15 and a session password identifier 16. The session password identifier 16 is used to track the user through the Repository screens and displays. If the user attempts to access a prohibited Repository screen, the session is automatically terminated. The termination procedure protects the user from intercepting the session password identifier, thus prohibiting the user from navigating to other prohibited screens. A timeout session for user inactivity or access to a wrong screen is also envisioned as part of the present invention. The login name 15 and a session password identifier 16 are the first line of security defenses. For added security, access to individual Repository Units such as, Components, Frameworks, or other objects are controlled through an object access list which creates a "security code". This access list is inspected when the user attempts to access the Repository Unit Components, including Frameworks, or other objects. The security code is carried throughout the session through hidden variables in a dynamically created HTML which is generated from the CGI-WIN programs. It is preferred that all programs for creating dynamic Repository web pages are stored in the CGI-WIN directory. In other embodiments, the Web Server may use other CGI mechanisms such as, CGI-DOS, or mechanisms such as JAVA or JAVA script. The Repository System supports access levels of Browse Access, Check-out Access, and Administrative Access. Unauthorized access attempts are logged into a special audit file for later resolution by a user or a security administrator with the appropriate privileges. To further add to the security of the system, Repository Units are not accessible through a direct URL, or other web page pointers and may be encrypted. The encrypted Repository Units are only accessible through the windows CGI-WIN program, thus, permitting only logged-in users who have navigated to the appropriate check-out screen to have access thereto. In an alternate embodiment, a secure socket layer is provided for additional measures of security between the Repository Client and the Repository Server. In this mode, a private key is issued to the Repository Client and the Repository Server, wherein the key is utilized for all transmissions over the TCP socket layer. Once logged-in the user searches the Repository databases by use of search and display templates. The search and display engines of the Repository System utilize these templates to semi-automate searches and display results in a user controlled environment by employing System Attributes. The templates allow the user to construct sets of rules that permit the search to be targeted to reach specific Repository Units. The user has access to all Attributes that are within the users security limits. Referring to FIG. 4 a Repository Search Template 17 is shown which is based on user assigned and system defined Attributes assigned to the Repository Unit at check-in. The Search Template 17 provides the user with a quick and organized method for performing Repository searches based on the stored attributes. The Attributes allow for flexible characterization of the Repository Units--e.g., the ability to fully characterize a Repository Unit from a technical, quality, business, and documentation stand point. Initially, the Searching Template prompts the user for a new template name 18, Attribute Search Expression 19, Text Search String 20, and a Binary Search String 21. The user does not have to include all information requested by the Repository Search Template 17; however, it is preferred that the user include the new user template name 18 and at least one of the other requested category information--i.e., Attribute Search Expression 19, Text Search String 20, or a Binary Search String 21. The new user template name 18 identifies the search template 17 in the user's individual Search Template Repository. The Search Templates 17 and 25 (as referred to in FIG. 5) are able to be utilized during subsequent Repository searches. The Repository Search Template 17 also includes a list of Attributes displayed in the Frequently Used Attribute Interactive Display 23, and a list of Attribute Operands 22. FIG. 5 shows a complete Attribute List 26 as partially shown. The complete Attribute list contains a list of all known user accessible Attributes 23 in the system. These Attributes 23 are user assigned or Repository generated and are stored in a Repository Unit Descriptor File. An illustrative example of a Search Template for a software engineer user may be as follows:
______________________________________
TemplateName=WellUsedUtilities
Attribute Expression:
(Type=Software) && (SubType=Utility)
&& (Language=C) && (Re-useCount>10)&&
(CodeCommentRatio<=2)
or
TemplateName=UsedUtilities
Attribute Expression:
(Type=Software) && (SubType=Utility)
(CreationDate>6/5/95)
______________________________________
Referring to FIG. 2a the user accesses the Repository Server 47 via a web browser 39 that is known in the industry. The web browser accesses the Repository Server which, in turn, searches for the requested Repository Units or Components 40. The Repository Server searches the unrestricted Repositories and routes a list of Repository Units 14 to the user's desktop (via the browser). The user then selects certain Repository Units from the Component List 42 and forwards the same to the Repository Server. The Repository Server then searches the appropriate Repositories for the Repository Units 42 and thereafter displays the information on the requested Repository Units on the user's desktop. The Repository Units are then scrutinized by the user and thereafter identified for downloading via download instructions 45 to the Repository Server 47. Once the download instructions are processed by the Repository Server 47 a FTP or HTTP download of the Repository Unit 45 is generated. At this point the user loads the Repository Unit directly into a new application, re-uses the Repository Unit by combining it with other Repository Components, or makes any revisions thereto. If the Repository Unit is not executable on the user's desktop, simulation techniques as described above, are utilized. Of course this process is directed towards a specific project goal by any Repository Client or Repository Server as fully described above. For example, using the alternate example above the user may search for Repository Units that have characteristics associated with "(Type=Software)", "(SubType=Utility)", and "(CreationDate>6/5/95)." To search the Repository Server for the requested Repository Units, the user enters Attributes "Software", "Utility", and "created subsequent to 6/5/95" into the Attribute Search Expression Dialog Box 19 or, in the alternative, "clicking" on the appropriate Attribute 23 in the Frequently Used Attributes Interactive Display 24 in the Search Templates 17, 25 or 27 and entering a new user template name 18 as described above. The user can specify in greater detail which Repository Units are required by defining a Text String 20 or adding further Operands 22 to the Attribute Search Expression 19. The addition of search Operands 22 expands or narrows the user's search depending on the user's search intentions. Referring to FIG. 6, template 27 allows searching by pre-defined templates which are assigned to specific users. The interface of the templates hides the complexity of the Attribute 19 expression that defines the search criterion. Other examples of searching templates include Text Pattern Search Templates in which text based Repository Units are searchable using key words and phrases. There are no practical limits to the number of templates that the user may define. Referring to FIG. 7 a Display Template Construction Form 28 is shown. The Display Template Construction Form 28 guides the user in the construction of a custom display template which allows the user to examine search results in a user friendly environment. Alternate display template constructions are envisioned thereby allowing the individual user to construct any number of templates that are user friendly to that user. Custom Display Templates formed from the Display Template Construction Form 28 allow the user to display only requested information on the Display Template, i.e., Display Form. The Display Templates further allows the user to inspect the Repository Units, and thereafter, download the Repository Units. In the preferred embodiment, the Display Templates are HTML formatted text files that comprise Attribute 23 and attribute value place holder units that are visual notations of potential attributes. Thus, when the Repository Server displays a Repository Unit using the Custom Display Template, the Repository Server generates a dynamic HTML File via the CGI Program, which is thereafter displayed on the Repository Client browser window. Referring to FIG. 8, a Search Result Page 60 displays search results in a dynamic page format. As such, if there are zero matches 61 the Result Page 60 indicates that no matches were found, and thereafter provides suggestions 62 to improve the user's search results. If one match is found the dynamic page is skipped and immediately proceeds to the component display results 63. If "<NUM" (less than a user or System defined number) results are found then a single line displaying the component name and a short description 64 thereof is provided for each match. These single lines are implemented in embedded forms so that when a line is "clicked", a requested Repository Unit is displayed in a "Unit Display Page" 65. If ">=NUM" 66 (greater than or equal to a user or System defined number) results are found then a line displaying each Repository Unit with its Attributes are displayed. This display allows the list of Repository Units to be re-sorted by Attribute 23 each time an Attribute is "clicked." These lines are implemented in embedded forms so that when a line is "clicked", a requested Repository Unit is displayed in the "Unit Display Page" 65. Searching hints 67 are provided when there are greater than a predefined number of Repository Units listed. When the user performs a search using Attributes 23 that are invalid or have permission restrictions, an error message 68 is displayed on the "Unit Display Page" 65 and the requested search is not initiated. Once the Repository Unit is checked-out, the repository tools create a purchase record for the appropriate billing account, and updates the re-use count in the Repository database as well as the appropriate information concerning the re-user. The Repository Server also includes other administrative access and functions, including amongst others, adding and deleting users, updating system files such as password and access lists, completing the check-in process for new Repository Units, as well as checking security logs and resolving security issues. Users with administrative access via appropriate permission can elect to produce reports or search a company for employees with specific skills. Further, corporate accounting departments can utilize the Repository for generating billing information and determining the asset value of the Repository itself. The above is only a representative example of administrative functions utilizing the Repository, and as such, other embodiments and administrative functions are envisioned hereto. As an example of alternate embodiments the present invention can be used as an effective staff management tool, such as determining engineering capabilities--i.e., object creation and deposit within the MXP Repository--or for system diagnostic capabilities. Repository Station Referring again to FIG. 2, the Repository Station 11 provides Repository Client capabilities and an additional set of tools that allows the user to manage a local Repository, such as the local disk Repositories 3, or a technology-specific Repository CD 4. The Repository Station 11 provides much of the same storage, searching, and cataloging functionalities that the full Repository System supports, preferably with the limitation of functions to the single independent Repositories 3 and 4 or other similar Repository storage areas. The Repository Station 11 Repositories are independently searchable--i.e., the Repository Server 10 does not have access to the Repository station's data or meta-data--utilizing Search Templates 17, 25 or 27 and Display Templates 28. It is preferred that the Repository Station 11 or similar station, include the following elements: Web Browser Software Major Portions of the Web Server Software for Searching Local Repositories Tutorial Information Web Pages Simulated or actual Operating Environment for PC Simulated or actual Development Environment for Windows Simulated or actual Application Environment Application Player--Helper Application Repository Unit Packager Used in Check-in--Helper Application Repository Un-packager Used in Check-out--Helper Application Repository-CD Access Software Compiler/Linker/Loader Tools for building checked-in and checked-out source code Repository Units Helper Applications are discussed in greater detail concurrently with the Repository Client analysis and discussion. Repository Client Users access the Repository Servers using Repository Client software. The Repository Client comprises a Repository Server access software set that provides the user with a full set of capabilities to interact with the Repository Server. In the preferred embodiment, Repository Client software includes: Web Browser Software Other means to simultaneously access multi media cross platform information Local Tutorial Information Web Pages Simulated or actual Operating Environment For PC Simulated or actual Development Environment for Windows Simulated or actual Applications Environment MXP Application Player--Helper Application MXP Application Packager Used in Check in--Web based Helper Application MXP Repository Unit Un-packager Used in Check-out--Web based Helper Application Compiler/Linker/Loader Tools for building checked-out source code Repository Units The Repository Client and Repository Station contain Helper Applications that provide enhanced capabilities for the Repository Client and Repository Station. Referring to FIG. 9 the preferred embodiment separates these applications into three distinct categories: Application Player 51, Repository Unit Packager 52, and Repository Unit Un-packager 53. Alternate embodiments, including other Helper Application categories, are also envisioned. The Application Player 51 preferably provides the following capabilities: Plays Component Repository Units that are downloaded from the Repository 51a (these are MXP compliant software units) Loads Frameworks that are downloaded from the Repository and allows Components to be loaded into the Framework, and plays the combined Application 51b Plays Repository Units that are Demonstration Modules 51c The Repository Unit Packager 52 preferably provides the following capabilities: Windows Helper Application that allows the user to select the files to be combined into a Repository Unit 52a Allows the user to assign Attributes to the Repository Units 52b Creates a package that can be transferred via FTP or HTTP to the Repository Server for incorporation into the Repository 52c Lastly, the Repository Unit Un-packager 53a preferably provides the following capabilities: Selects the destination of the Repository Unit on the desktop directory structure 53a Selects partial contents of the Repository Unit for storage on the Target Computer 53b. The Repository Client or Repository Station does not require any special hardware; however, it is preferred that the Repository Client and Repository Station have multi-media capabilities and web browser software packages that are configured with the appropriate Helper Application. Repository Units The Repository System is designed to facilitate the re-use and visibility of RTES. This capability is provided by allowing a multitude of different file types to be utilized in describing, demonstrating, or providing support for a single or groups of files containing information about RTES. This allows the user to create a multimedia presentation of the RTES which includes an interactive demonstration. The Repository System organizes and processes Repository files as Repository Units. In the preferred embodiment the Repository Units are composed of the following files: Software Source Files such as C, C++, Basic, and Fortran A group of Software Source Files that make up a utility such as a Balanced Binary Tree Utility, a code download utility, or a checksum utility A group of Software Source Files that make up a sub-system such as a Device Driver, a signaling Software module, a Communication Interface, or a Fax Decode Engine A group of Software Source Files that make up a complete system such as a ATM switch, an Internet Router, or a V.34 Modem Test Software such as packet generation software, load tester software, or device simulation code Project make files which are used to build a software set Sample Data Files such as PCM voice samples, protocol packet samples, or random binary data files Voice Descriptions of projects which an engineer creates to verbally describe various aspects of his/her project Documentation Files from packages such as Framemaker, MS Word, or WordPerfect Picture Files that contain Drawings, Network Displays, Finite State Machines, or Data Description Diagrams A complete Project that contains any combination of the above file types One of ordinary skill in the art of the present invention will appreciate that other files can be composed to form other Repository Units that provide additional information about the RTES stored in the repository. It will also be apparent to one of ordinary skill in the art of the present invention that the above individual file lists also include other equivalent components. For example Documentation Files from packages such as Framemaker, MS Word, or WordPerfect also include, amongst others, QuattroPro, Professional Writer, and OfficeWriter. Repository Units also contain Attachments that provide current information to static files that are stored in the Repository. The preferred embodiment utilizes the following attachments: E-mail Threads so that the users can continually assist other users concerning Repository Units Newsgroups (Internet style) such as a Problem Report Group, a Users Group, or a Special Interest Group Expert Quality Ratings so that particular software specialist can inform future re-users of the RTES of the level of quality that can be expected from the Repository Unit Browse Count to record how may times the Repository Unit was browsed a particular Repository user, or a combination of several Repository users Re-use Count to record how many times the Repository Unit was checked out for re-use Purchase Count and Amount to record how many time a Particular Repository Unit was purchased, and the purchase price. One skilled in the art of the present invention can appreciate that other Attachments are contemplated for use with the present invention. The Repository Units are further characterized using analysis tools (software analysis). The analysis tools are started when the RTES is initially checked-in to the Repository Server. These tools allow the user to associate fixed and user defined Attributes to the RTES when the user checks software into Repository, as well as creating a set of standard quality index Attributes. The user also has the ability to include a desktop demonstration executable with the re-used software at check-in or later, to be downloaded and run by the potential re-user of the software. The Repository Units are active entities which allow the addition of more attributes, re-use counts, and test suites. The Repository Units also allow the addition of quality attributes which include the capability of tracking e-mail threads or other problem report threads relating to any particular Repository Unit, or be annotated with business related attributes such as development cost and sales price. The Quality Attributes also track revisions of the Repository Units within the Repository, view the particular Repository Units without having to access or display any prior revisions, as well as support multimedia capabilities and supply security to the Repository Units. Once the software has been accepted for re-use it is downloaded to the desktop and a record of such download is then generated. To achieve the maximum benefit of the Repository, a categorization feature is provided by the Repository System. The full value includes, amongst other variables, the ability to fully characterize a component from a technical, quality, business, and documentation perspective. The Repository Units further have the capabilities of containing whole projects, Components, and Frameworks. As mentioned previously, the Repository Search Template 17 includes a list of Attributes 23 and Attribute Operands 22. These Attributes 23 are user assigned or Repository generated and are stored in a Component Descriptor File. The Search Template 17 is implemented as a BOOLEAN expression of Attributes 23 which is evaluated against each Repository's stored components to determine when a desired Repository Unit is identified. It is preferred that the Attributes 23 be constructed into BOOLEAN expressions using the existence of the Attribute 23 in association with the Repository Units, or in the alternative, as a comparison of the Value associated with a given Attribute 23 assigned to a Repository Unit. In the preferred embodiment, the BOOLEAN expressions, i.e., the list of Attribute Operands 22 include, but are not limited, to the following expressions: ##STR1## Where "AND" is a logical "AND" operation; "OR" is a logical "OR" operation; "NOT" is a logical "NOT" operation; "EQL" is an arithmetic equals operation to compare two like data types, i.e., string to string, integer to integer, dollar value to dollar value (the result of this operation is a BOOLEAN TRUE or FALSE); "LES" is an arithmetic less than operation to compare like data types (the result of this operation is a BOOLEAN TRUE or FALSE); "LEQ" is an arithmetic less than or equal operation to compare two data types (the result of this operation is a BOOLEAN TRUE or FALSE); "GTR" is an arithmetic greater than operation to compare two data types (the result of this operation is a BOOLEAN TRUE or FALSE); "GEQ" is an arithmetic greater than or equal operation to compare two data types (the result of this operation is a BOOLEAN TRUE or FALSE); and "SUBSTR" is a left operand test string that is a sub-string of the right operand substring. Arithmetic equivalents of the above may also be utilized--e.g., "<" is equivalent to "LES." Additionally, any combination of the above Operands 22 can be utilized to facilitate other user defined Repository searches. It is preferred, however, that boolean expressions that contain comparisons of the Value of an Attribute 23 conform to the Attribute's 23 format as well. Additional analysis information contained in the Components and Frameworks include Operating System Call Return Checking, Operating System Call Utilization, System Resource Utilization, and Memory Space Calculation. Embedded source code analysis information includes object description, comment to code ratio, like-word file, key-word file, complexity analysis, LINT results, and software line count. How to Use Referring to FIG. 10, a RTES Repository (Repositories)70, 72 internetworked to product development groups 74, 76, customers 78, technology partners 80 and corporate divisions, such as marketing 82, product management 84, and accounting departments 86, is shown. As previously stated the Repository comprises in-house server or local disk Repositories 3, Repository technology-specific CD Repositories 4, third party Repositories 5 accessed via the Internet or other internetworked systems, other internal off-site corporate Repositories 6 accessed via the Internet or other internetworked system, or Stand-alone Repository Systems. In the preferred embodiment, the product development groups 74, 76 access the RTES Repository 70, 72 via the Repository Server (not shown), which, after several steps as enumerated above, are able to download or check-out, i.e., unpackage, the requested Repository Units--via FTP or HTTP mechanisms--to the development group 74, 76 user's desktop. In particular, the product development groups 74, 76 are provided with visibility into RTES stored in the Repository database, and more particularly, reused RTES Components and Frameworks, attribute search results, multimedia presentations, schedules, product, demonstrations, Repository Unit E-mail threads, and Repository Unit problem threads. The product development groups 74, 76 are further able to deposit, i.e., check-in, units to the RTES Repository 70, 72, such as new RTES Components and Frameworks, attribute definitions, multimedia presentations, schedules, product demonstrations, Repository Unit E-mail, threads, and Repository Unit problem threads. This allows for the development and re-use of new products, and new features within existing products. Technology partners 80 are also provided with visibility into the RTES Components and Frameworks, wherein it is preferred that the technology partners 80 be provided with visibility into Repository Unit E-mail threads, and Repository Unit problem threads, multimedia presentations, schedules, product demonstrations for integration purposes and integration tests. The technology partners 80 are able to check-in attribute definitions, multimedia presentations, schedules, pricing/cost attributes, and Search criterion. This allows the technology partners 80 to perform Integration tests, which, in turn, allows for inter-operating software with other technology partners. Of course the proper protocols for both technology partners 80 and product development groups 74, 76, as enumerated above, must be met when checking-in and checking out RTES, as well as accessing certain Repositories. It is further preferred that customers 78 have access to the RTES Repository 70,72 as well. Customers 78 are provided with visibility into attribute search results, multimedia presentations, and product demonstrations. Customers 78 are further able to check-in search criterion to the RTES Repository 70,72. This allows Customers 78 to purchase RTES software products. Again to access the Repository, and check-in and check-out Components or Frameworks, the proper protocol as enumerated above must be satisfied. Lastly, Product Marketing Groups 82 and other corporate divisions 84, 86 also have access to the Repository system. In this instance it is preferred that the Product Marketing Groups 82 are provided with visibility into attribute search results, multimedia presentations, schedules, and product demonstrations. In turn, the Product Marketing Groups 82 are able to check-in attribute definitions, multimedia marketing presentations, product demonstrations, and attribute search criterion. Alternate embodiments with regard to checking-in and checking-out of Components and Frameworks, and other information from the RTES Repository are also envisioned with regard to the product development groups 74,76, customers 78, technology partners 80 and corporate divisions 82, 84, 86. When a user desires to fully evaluate a RTES module stored in the Repository of the present invention, the user is provided with the capability of executing the software retrieved from the repository and observing the characteristics of the RTES module while in operation. The user must also have the ability to vary the configuration parameters or input data so that the RTES module under evaluation can be fully characterized for the proposed application. This is accomplished by an RTES application player. This RTES Repository application player capability allows the user to view the RTES module stored in the Repository and is instrumental in promoting reuse. Since RTES modules can be exercised by a user and then suitability for reuse assessed. Referring to FIG. 11, an example of such capability is illustrated with the Repository contents for a balanced binary tree utility. This type of software utility typically runs in an embedded environment where it is utilized by various types of software sub-systems such as Protocol Software or embedded database applications. The creator of a software module like the balanced binary tree utility has the capability of including with the Repository Unit one or more Desktop applications, such as a Windows or Unix application, to provide a graphical user interface (GUI). This would involve the creation of a Windows (or Unix) program shell that is built with the utility software to provide the mechanisms for data input and the display of results. The prospective re-user of the utility has the capability of downloading and executing this software on a desktop machine that matches one of the desktop applications associated with the utility that is stored in the Repository (e.g. Windows Desktop machine would download only Windows executables). It is not always possible for the creator of an embedded software module to create a desktop application with a GUI, though, because the user may not have the specific skills required to write, for example, a Windows application. The user also may not have development time scheduled for that purpose. In order to account for this situation and still provide visibility, the MXP Repository System allows embedded software that is written to an API that conforms to Real-Time Embedded Operating System primitives (such as MXP, PSOS, VxWorks) to be executed in an emulation environment on the Repository Client. The Repository Client (and Repository Station) includes an environment and utility that loads embedded software onto the Desktop and allows it to be executed. This utility is referred to as the RTES Application Player. The RTES Application Player Desktop utility performs a link operation with an embedded software build downloaded from the RTES Repository. The RTES Application Player includes emulation utilities for the OS primitives associated with real-time embedded operating systems such as timing and synchronization, messaging, task scheduling, and memory management. The utility starts the embedded software as if it is running in the embedded environment, and allows the user to stimulate the embedded software through its OS primitives. For example, when the embedded software includes an input message queue that a task in the embedded software utilizes, the MXP Application Player assists the user in building a message and then allows the user to inject that message on to the specified queue. The embedded software that is executing in the RTES Application Player may then read the message on that queue and perform its operations based on the received message. The RTES application monitors the embedded application from its interface with the OS primitives, and provides the user with a graphical view of OS resource utilization and interaction. The Application Player also includes simulation support for standard interfaces to devices such as communication controllers, dual port RAMS, flash, LCD/LED displays, and other devices common to embedded systems. Applications which utilize these standard interfaces allow enhanced interaction through the Application Player, e.g., viewing simulated displays or connecting multiple applications through communication interfaces. Other mechanisms may be employed by the RTES Application Player to execute full embedded target specific builds that are stored in RTES Repository on matching target hardware, e.g., a reference hardware design or standard design such as a VME general purpose board. These techniques are well known in the industry, for example, the Application Player can utilize the MXP (VxWorks or other RTOS) to load a target specific module on a Target that is running the RTOS Shell. This technique has a disadvantage, though, of requiring specific target hardware in order to demonstrate the real time embedded software Repository Unit. Preferred and alternative embodiments of the present invention have now been described in detail. It is to be noted, however, that this description of these specific embodiments is merely illustrative of the principles underlying the inventive concept. It is therefore contemplated that various modifications of the disclosed embodiments will, without departing from the spirit and scope of the present invention, be apparent to persons of ordinary skill in the art.
|
Same subclass Same class Consider this |
||||||||||