U.S. patent application number 12/939634 was filed with the patent office on 2012-05-10 for characterizing interface evolution and consumer roles in module systems.
This patent application is currently assigned to ORACLE INTERNATIONAL CORPORATION. Invention is credited to Alexander R. Buckley.
Application Number | 20120117538 12/939634 |
Document ID | / |
Family ID | 46020864 |
Filed Date | 2012-05-10 |
United States Patent
Application |
20120117538 |
Kind Code |
A1 |
Buckley; Alexander R. |
May 10, 2012 |
CHARACTERIZING INTERFACE EVOLUTION AND CONSUMER ROLES IN MODULE
SYSTEMS
Abstract
The disclosed embodiments provide a system that facilitates the
development and maintenance of a software program. This system
includes a software development kit (SDK) and a runtime system for
the software program. During operation, the system obtains a role
associated with a dependency of a consumer in the software program
on an interface. Next, the system obtains a compatibility policy
for the interface. Finally, the system uses the role and the
compatibility policy to manage use of the interface by the consumer
in the software program.
Inventors: |
Buckley; Alexander R.;
(Cupertino, CA) |
Assignee: |
ORACLE INTERNATIONAL
CORPORATION
Redwood City
CA
|
Family ID: |
46020864 |
Appl. No.: |
12/939634 |
Filed: |
November 4, 2010 |
Current U.S.
Class: |
717/120 |
Current CPC
Class: |
G06F 8/71 20130101; G06F
8/70 20130101 |
Class at
Publication: |
717/120 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A computer-implemented method for facilitating the development
and maintenance of a software program, comprising: obtaining a role
associated with a dependency of a consumer in the software program
on an interface; obtaining a compatibility policy for the
interface; and using the role and the compatibility policy to
manage use of the interface by the consumer in the software
program.
2. The computer-implemented method of claim 1, wherein the role
identifies the consumer as a caller or an implementer of the
interface.
3. The computer-implemented method of claim 2, wherein using the
role and the compatibility policy to facilitate use of the
interface by the consumer involves: using the compatibility policy
to characterize a change in the interface; if the change is
characterized as a binary-incompatible change, disabling use of the
interface by the caller; and if the change is characterized as a
source-incompatible change, disabling use of the interface by the
implementer.
4. The computer-implemented method of claim 3, wherein the
binary-incompatible change comprises a removal of an existing
function from the interface, and wherein the source-incompatible
change comprises an addition of a new function to the
interface.
5. The computer-implemented method of claim 3, wherein the change
is characterized using at least one of a version of the interface
and a reverse dependency constraint associated with the
interface.
6. The computer-implemented method of claim 1, wherein the consumer
is at least one of a class, a package, and a module.
7. The computer-implemented method of claim 1, wherein the role is
declared by the consumer or inferred from type declarations in the
consumer.
8. The computer-implemented method of claim 1, wherein the
compatibility policy is applied to the interface, a set of
interfaces, or the software program.
9. A system for facilitating the development of a software program,
comprising: a software development kit (SDK) for the software
program; and a runtime system for the software program, wherein the
SDK and the runtime system are configured to: obtain a role
associated with a dependency of a consumer in the software program
on an interface; obtain a compatibility policy for the interface;
and use the role and the compatibility policy to manage use of the
interface by the consumer in the software program.
10. The system of claim 9, wherein the role identifies the consumer
as a caller or an implementer of the interface.
11. The system of claim 10, wherein using the role and the
compatibility policy to facilitate use of the interface by the
consumer involves: using the compatibility policy to characterize a
change in the interface; if the change is characterized as a
binary-incompatible change, disabling use of the interface by the
caller; and if the change is characterized as a source-incompatible
change, disabling use of the interface by the implementer.
12. The system of claim 11, wherein the binary-incompatible change
comprises a removal of an existing function from the interface, and
wherein the source-incompatible change comprises an addition of a
new function to the interface.
13. The system of claim 11, wherein the change is characterized
using at least one of a version of the interface and a reverse
dependency constraint associated with the interface.
14. The system of claim 9, wherein the consumer is at least one of
a class, a package, and a module.
15. The system of claim 9, wherein the compatibility policy is
applied to the interface, a set of interfaces, or the software
program.
16. A computer-readable storage medium storing instructions that
when executed by a computer cause the computer to perform a
function for facilitating the development and maintenance of a
software program, the function comprising: obtaining a role
associated with a dependency of a consumer in the software program
on an interface; obtaining a compatibility policy for the
interface; and using the role and the compatibility policy to
manage use of the interface by the consumer in the software
program.
17. The computer-readable storage medium of claim 16, wherein the
role identifies the consumer as a caller or an implementer of the
interface.
18. The computer-readable storage medium of claim 17, wherein using
the role and the compatibility policy to facilitate use of the
interface by the consumer involves: using the compatibility policy
to characterize a change in the interface; if the change is
characterized as a binary-incompatible change, disabling use of the
interface by the caller; and if the change is characterized as a
source-incompatible change, disabling use of the interface by the
implementer.
19. The computer-readable storage medium of claim 18, wherein the
binary-incompatible change comprises a removal of an existing
function from the interface, and wherein the source-incompatible
change comprises an addition of a new function to the
interface.
20. The computer-readable storage medium of claim 18, wherein the
change is characterized using at least one of a version of the
interface and a reverse dependency constraint associated with the
interface.
Description
RELATED APPLICATION
[0001] The subject matter of this application is related to the
subject matter in a co-pending non-provisional application by
inventors Mark B. Reinhold, Alexander R. Buckley, Jonathan J.
Gibbons and Karen M P Kinnear, entitled "Polyphasic Modules for
Software Development," having Ser. No. 12/771,121, and filing date
30 Apr. 2010 (Attorney Docket No. SUN09-0752).
BACKGROUND
[0002] 1. Field
[0003] The present embodiments relate to module systems for
software development. More specifically, the present embodiments
relate to techniques for characterizing interface evolution and
consumer roles in module systems.
[0004] 2. Related Art
[0005] Within software systems, increasing sophistication and
functionality are typically accompanied by corresponding increases
in code size and complexity. For example, the addition of new
features to a software program may require the implementation of
new components, which in turn may increase the number of
dependencies within the software program. Over time, changes to the
software program may lead to increases in defects, debugging time,
redundancy, and lack of readability. The continued development of a
software system without effective complexity management may
consequently reduce performance and increase maintenance risk to
the point of rendering the software system unusable and/or
unmanageable.
[0006] Issues associated with increasing software complexity may be
mitigated by modularizing software systems. Modular software
utilizes components that are self-contained and that facilitate a
separation of concerns. For example, individual modules may be
developed, tested, and used independently of each other in a
software system. In addition, a module's functionality and
dependencies may be explicitly declared through an interface
provided by the module. Modularized software may thus be
significantly more maintainable, easier to understand, and less
complex than monolithic software.
[0007] Hence, increased use of modularity may improve the design,
maintenance, performance, scalability, and growth of software
systems.
SUMMARY
[0008] The disclosed embodiments provide a system that facilitates
the development and maintenance of a software program. This system
includes a software development kit (SDK) and a runtime system for
the software program. During operation, the system obtains a role
associated with a dependency of a consumer in the software program
on an interface. Next, the system obtains a compatibility policy
for the interface. Finally, the system uses the role and the
compatibility policy to manage use of the interface by the consumer
in the software program.
[0009] In some embodiments, the role identifies the consumer as a
caller or an implementer of the interface.
[0010] In some embodiments, using the role and the compatibility
policy to facilitate use of the interface by the consumer involves
using the compatibility policy to characterize a change in the
interface. If the change is characterized as a binary-incompatible
change, the system disables use of the interface by the caller. If
the change is characterized as a source-incompatible change, the
system disables use of the interface by the implementer.
[0011] In some embodiments, the binary-incompatible change includes
a removal of an existing function from the interface, and the
source-incompatible change includes an addition of a new function
to the interface.
[0012] In some embodiments, the change is characterized using a
version of the interface and/or a reverse dependency constraint
associated with the interface.
[0013] In some embodiments, the consumer is a class, a package,
and/or a module.
[0014] In some embodiments, the role is declared by the consumer or
inferred from type declarations in the consumer.
[0015] In some embodiments, the compatibility policy is applied to
the interface, a set of interfaces, or the software program.
BRIEF DESCRIPTION OF THE FIGURES
[0016] FIG. 1 shows the life cycle of a software program in
accordance with an embodiment.
[0017] FIG. 2 shows the development and maintenance of a software
program using a module system in accordance with an embodiment.
[0018] FIG. 3 shows the role-based management of interaction
between a consumer and an interface in accordance with an
embodiment.
[0019] FIG. 4 shows an exemplary use of consumer roles and
compatibility policies in a software program in accordance with an
embodiment.
[0020] FIG. 5 shows a flowchart illustrating the process of
facilitating the development and maintenance of a software program
in accordance with an embodiment.
[0021] FIG. 6 shows a flowchart illustrating the process of using a
role and a compatibility policy to manage use of an interface by a
consumer in accordance with an embodiment.
[0022] FIG. 7 shows a computer system in accordance with an
embodiment.
[0023] In the figures, like reference numerals refer to the same
figure elements.
DETAILED DESCRIPTION
[0024] The following description is presented to enable any person
skilled in the art to make and use the embodiments, and is provided
in the context of a particular application and its requirements.
Various modifications to the disclosed embodiments will be readily
apparent to those skilled in the art, and the general principles
defined herein may be applied to other embodiments and applications
without departing from the spirit and scope of the present
disclosure. Thus, the present invention is not limited to the
embodiments shown, but is to be accorded the widest scope
consistent with the principles and features disclosed herein.
[0025] The data structures and code described in this detailed
description are typically stored on a computer-readable storage
medium, which may be any device or medium that can store code
and/or data for use by a computer system. The computer-readable
storage medium includes, but is not limited to, volatile memory,
non-volatile memory, magnetic and optical storage devices such as
disk drives, magnetic tape, CDs (compact discs), DVDs (digital
versatile discs or digital video discs), or other media capable of
storing code and/or data now known or later developed.
[0026] The functions and processes described in the detailed
description section can be embodied as code and/or data, which can
be stored in a computer-readable storage medium as described above.
When a computer system reads and executes the code and/or data
stored on the computer-readable storage medium, the computer system
performs the functions and processes embodied as data structures
and code and stored within the computer-readable storage
medium.
[0027] Furthermore, functions and processes described herein can be
included in hardware modules or apparatus. These modules or
apparatus may include, but are not limited to, an
application-specific integrated circuit (ASIC) chip, a
field-programmable gate array (FPGA), a dedicated or shared
processor that executes a particular software module or a piece of
code at a particular time, and/or other programmable-logic devices
now known or later developed. When the hardware modules or
apparatus are activated, they perform the functions and processes
included within them.
[0028] FIG. 1 shows the life cycle of a software program in
accordance with an embodiment. The life cycle begins with a
compilation 104 phase, in which source code for the software
program is converted into an executable format. Next, the compiled
software program undergoes a testing 106 phase to detect failures,
defects, and/or other issues in the implementation of the software
program. For example, testing 106 may be carried out to analyze the
correctness, security, scalability, performance, maintainability,
and/or usability of the software program.
[0029] After testing 106, packaging 108 of the software program may
involve creating a software package in an archive format from the
software program's executable code. The software package may then
undergo deployment 110 and installation 112 on a computer system.
For example, a web application may be deployed and installed on a
server computer, while a native application may be deployed and
installed on multiple personal computers. Finally, execution 114 of
the software program allows the software program's intended
functionality to be provided to an end user.
[0030] Those skilled in the art will appreciate that changes such
as patches, upgrades, maintenance, and/or new releases may be
periodically made to the software program. Moreover, such changes
may be propagated through some or all of the phases of the life
cycle. For example, the addition of new features to the software
program may require that the software program be recompiled,
tested, packaged, deployed, installed, and executed with the new
features.
[0031] Those skilled in the art will also appreciate that changes
to the software program may increase the complexity of the software
program, which may eventually interfere with the maintainability,
usability, and/or performance of the software program. For example,
modifications to the software program may be difficult to document
and/or track across all phases 104-114 of the software program's
life cycle. Over time, such modifications may interfere with the
continued use and development of the software program by obscuring
the design of the software program, increasing redundancy, and
introducing new, unknown dependencies among components in the
software program.
[0032] To mitigate issues associated with increased software
complexity, a module system 102 may be used to facilitate the
development and maintenance of the software program. In one or more
embodiments, module system 102 uses modular information at all
phases 104-114 of the life cycle to manage dependencies in the
software program. Such polyphasic modularization may facilitate the
development of the software program by improving transparency,
cohesion, performance, scalability, and maintainability in the
software program. Management of polyphasic modules is discussed in
a co-pending non-provisional application by inventors Mark
Reinhold, Alexander Buckley, Jonathan Gibbons, and Karen Kinnear,
entitled "Polyphasic Modules for Software Development," having Ser.
No. 12/771,121, and filing date 30 Apr. 2010 (Attorney Docket No.
SUN09-0752), which is incorporated herein by reference.
[0033] FIG. 2 shows the development and maintenance of a software
program 210 using module system 102 in accordance with an
embodiment. As shown in FIG. 2, a software development kit (SDK)
202 and a runtime system 204 may interact with module system 102 to
manage software program 210 across all stages of the life cycle of
software program 210. For example, SDK 202 and runtime system 204
may correspond to the Java (Java.TM. is a registered trademark of
Oracle America, Inc.) Development Kit (JDK) and Java Runtime
Environment (JRE).
[0034] As mentioned above, module system 102 may use polyphasic
modules to facilitate the development of software program 210. In
particular, polyphasic modularization of software program 210 may
begin with the creation of module declarations for a set of modules
206-208 to be used in software program 210.
[0035] In one or more embodiments, modules 206-208 correspond to
standalone components in software program 210 that may be
independently programmed, tested, and modified. Each module 206-208
may be defined, organized, and used through a corresponding module
identity and module declaration. In addition, an interface to a
module may be based on the members of the module. For example, the
module may be accessed through public functions and/or data in the
module's members. Logical boundaries between modules 206-208 may
further be enforced by enabling inter-module interaction only
through the interfaces to the modules, thus effectively hiding
implementation details of modules 206-208 from one another.
[0036] In other words, modules 206-208 may correspond to
encapsulated abstractions of functionality in software program 210
with well-defined capabilities and dependencies. Modules 206-208
may thus provide a large amount of flexibility in organizing the
structure of software program 210. For example, Java classes may be
grouped into modules 206-208 based on the functionality and/or use
of the classes in software program 210 instead of language-based
constraints such as package membership.
[0037] In one or more embodiments, module declarations for modules
206-208 are obtained separately from source code for software
program 210. For example, module declarations for modules 206-208
in a Java program may be stored in module definition files that are
separate from source files containing Java classes, interfaces,
enumerations, and/or annotation types. Such decoupling of module
declarations from module implementations may further enable the
creation of modules 206-208 based on factors that facilitate the
design and development of software program 210, such as separation
of concerns, scalability, and performance.
[0038] The independent creation and procurement of module
declarations may additionally allow module system 102 to begin
modularizing software program 210 before software program 210 is
compiled. For example, module system 102 may allow module
declarations for modules 206-208 to be created (e.g., using SDK
202) before development of source code for software program 210 is
complete. Module system 102 may proceed with using the module
declarations to manage dependencies in software program 210 through
the compilation, testing, packaging, deployment, installation, and
execution phases of the life cycle of software program 210.
[0039] In one or more embodiments, SDK 202 and runtime system 204
provide mechanisms for characterizing the evolution of interfaces
for modules 206-208 and determining the impact that changes to the
interfaces may have on consumers of modules 206-208. First, SDK 202
and runtime system 204 may obtain a role associated with a
dependency of a consumer in software program 210 on an interface.
The role may identify the consumer as a caller of the interface
and/or an implementer of the interface. Next, SDK 202 and runtime
system 204 may obtain a compatibility policy for the interface. The
compatibility policy may characterize changes to the interface over
time.
[0040] SDK 202 and runtime system 204 may then use the role and
compatibility policy to assess the compatibility of the interface
with the consumer. In particular, SDK 202 and runtime system 204
may use the compatibility policy to characterize a change in the
interface as binary-incompatible and/or source-incompatible.
[0041] The binary-incompatible change may correspond to removal of
an existing function from the interface, while the
source-incompatible change may correspond to addition of a new
function to the interface. As a result, use of the interface may be
disabled for callers of the interface if the change is
binary-incompatible. Conversely, if the change is
source-incompatible, use of the interface may be disabled for
implementers of the interface. SDK 202 and runtime system 204 may
thus use the compatibility policy and role to manage use of the
interface by the consumer in software program 210, as discussed in
further detail below.
[0042] FIG. 3 shows the role-based management of interaction
between a consumer 302 and an interface 304 in accordance with an
embodiment. Consumer 302 may correspond to a component in a
software program with a set of dependencies 306 and a set of type
declarations 308. For example, consumer 302 may be a class,
package, library, module, distributed object, and/or compilation
unit.
[0043] Interface 304 may define a set of functions through which
components in the software program may interact. For example,
interface 304 may correspond to an application programming
interface (API), an abstract class or type, a module interface,
and/or other entity that provides a point of interaction between
software components. Consequently, consumer 302 may include a
dependency on interface 304 if consumer 302 uses interface 304 to
interact with other components in the software program. For
example, consumer 302 may be a Java compilation unit that declares
a dependency on interface 304 through a module declaration, package
import statement, method call, and/or implementation of interface
304.
[0044] Furthermore, the dependency of consumer 302 on interface 304
may be associated with a role 314. As mentioned above, role 314 may
identify consumer 302 as a caller and/or implementer of interface
304. In particular, role 314 may identify consumer 302 as a caller
of interface 304 if consumer 302 calls functions defined in
interface 304, or role 314 may identify consumer 302 as an
implementer of interface 304 if consumer 302 implements functions
defined in interface 304.
[0045] Role 314 may also be obtained in a variety of ways. For
example, role 314 may be explicitly declared in a module and/or
package declaration for consumer 302 using an identifier such as
"calls" or "implements," or role 314 may be inferred from the use
of Java keywords such as "extends" or "implements" in type
declarations 308.
[0046] In one or more embodiments, role 314 facilitates use of
interface 304 by allowing changes to interface 304 to be
characterized in terms of compatibility with consumer 302. Such
characterization may further be enabled by obtaining a
compatibility policy 316 that describes the "evolution" of
interface 304 over time as new functions are added to interface 304
and existing functions are modified and/or removed. For example,
compatibility policy 316 may identify the types of changes (e.g.,
additions, modifications, deletions) included in newer versions of
interface 304, as well as the functions affected by the changes. As
with role 314, compatibility policy 316 may be explicitly stated or
inferred. For example, compatibility policy 316 may be specified
using one or more reverse dependency constraints 312 of interface
304, as discussed below with respect to FIG. 4. Alternatively,
compatibility policy 316 may be deduced by identifying patterns in
changes made across different versions of interface 304.
[0047] More specifically, role 314 may be compared with
compatibility policy 316 to determine if a given version 310 of
interface 304 is compatible with consumer 302. First, changes
included in version 310 of interface 304 may be characterized using
compatibility policy 316. In addition, each change may be
characterized as a binary-incompatible change that removes an
existing function from interface 304 and/or as a
source-incompatible change that adds a new function to interface
304. The binary-incompatible change may thus produce an error
(e.g., runtime error) if a call to the removed function is
attempted, while the source-incompatible change may produce an
error (e.g., compilation error) if an implementation of interface
304 does not include the added function and is thus incomplete.
Conversely, the binary-incompatible function removal may not
interfere with an implementation of interface 304 that still
contains the removed function. Along the same lines, the
source-incompatible function addition may not affect calls to
existing functions defined by interface 304.
[0048] As a result, use of version 310 of interface 304 by consumer
302 may be disabled if role 314 identifies consumer 302 as a caller
and version 310 contains a binary-incompatible change. Likewise,
use of version 310 of interface 304 by consumer 302 may be disabled
if role 314 identifies consumer 302 as an implementer and version
310 contains a source-incompatible change. Incompatibilities
between consumer 302 and version 310 may then be resolved by
matching consumer 302 with older versions of interface 304 that do
not conflict with the method calls and/or implementations of
consumer 302.
[0049] Those skilled in the art will appreciate that changes to
interface 304 may prevent both callers and implementers from using
interface 304 unless corresponding changes are made to the method
calls to and/or implementations of interface 304. For example, a
new version of interface 304 may contain both function additions
and deletions and/or modify existing functions from a previous
version of interface 304. To mitigate changes required of consumers
(e.g., consumer 302) to maintain compatibility with new versions of
interface 304, compatibility policy 316 may specify a set of rules
that guide the creation of new versions of interface 304 based on
changes to interface 304.
[0050] For example, compatibility policy 316 may allow
binary-incompatible changes to be made to interface 304 when a
minor component of version 310 is incremented (e.g., "y" in version
"x.y.z") and source-incompatible changes to be made when a major
component of version 310 is incremented (e.g., "x" in version
"x.y.z"). As a result, a version increase from 1.0 to 1.1 may be
used by implementers of version 1.0 but not by callers of version
1.0. However, a version increase from 1.0 to 2.0 may contain
significant changes that prevent both callers and implementers of
version 1.* from using version 2.0.
[0051] Conversely, compatibility policy 316 may allow
source-incompatible changes when a minor component of version 310
is incremented and binary-incompatible changes when a major
component of version 310 is incremented. Callers of version 1.0 may
thus be able to use any version that is at least 1.0 and less than
2.0, while implementers of version 1.0 may not be able to use even
version 1.1.
[0052] As another example, compatibility policy 316 may allow
binary-incompatible changes to be included in odd-numbered minor
versions and source-incompatible changes to be included in
even-numbered minor versions. Consequently, a version change from
1.0 to 1.1 may be used by implementers of version 1.0 but not by
callers of version 1.0. In turn, a version change from 1.1 to 1.2
may be used by callers of version 1.1 but not by implementers of
version 1.1.
[0053] Furthermore, compatibility policy 316 may be applied to
interface 304, a set of interfaces containing interface 304, and/or
the software program. In other words, compatibility policy 316 may
have a scope that is local to interface 304, specific to a set of
interfaces, and/or global. Local compatibility policies may
additionally override global compatibility policies to allow
interface providers to select compatibility policies for individual
interfaces. For example, a compatibility policy for one interface
may utilize a three-component version (e.g., 1.0.0) for the
interface to enable finer-grained tracking of changes to the
interface, while another compatibility policy for a different
interface may use a two-component version (e.g., 3.1) to describe
changes to the interface.
[0054] Those skilled in the art will also appreciate that roles and
compatibility policies may be used to manage interaction among
software components outside module-based environments. In
particular, consumer roles and compatibility policies may be
utilized in any environment that decouples software functionality
from implementation and/or manages dependencies among software
components. For example, roles and compatibility policies may
mitigate incompatibility and/or simplify dependency resolution
among components of object-oriented software programs, distributed
objects, and/or software frameworks.
[0055] FIG. 4 shows an exemplary use of consumer roles and
compatibility policies in a software program in accordance with an
embodiment. As shown in FIG. 4, four modules 402-408 are associated
with module declarations that identify the modules and specify the
modules' dependencies. In particular, module 402 includes a name of
"M @ 1.0" and one dependency (e.g., "calls O @ 1.5+"). Module 404
has a name of "N @ 1.0" and a dependency of "implements O @ 1.1."
Module 406 has an identity of "O @ 1.6" and two reverse dependency
constraints (e.g., "permits caller `this @ [1.0, 2.0)`," "permits
implementer `this @ 1.6+`"), and module 408 has an identity of "O @
1.0" and a reverse dependency constraint of "permits implementer
`this @ [1.0, 2.0)`."
[0056] Moreover, the identifiers "calls" and "implements" in module
declarations for modules 402-404 may identify module 402 as a
caller of "O @ 1.5+" and module 404 as an implementer of "O @ 1.1."
In other words, roles associated with the dependencies of modules
402-404 on interfaces provided by other modules (e.g., modules
406-408) may be explicitly declared in the module declarations for
modules 402-404.
[0057] Similarly, reverse dependency constraints of modules 406-408
may specify compatibility policies for the interfaces provided by
modules 406-408. First, module 406 includes a reverse dependency
constraint of "permits caller `this @ [1.0, 2.0)`." As a result,
the compatibility policy for module 406 may allow other modules to
call functions in module 406 if the other modules express a
dependency on a module with the same name as module 406 (e.g., "O")
and a version ranging between 1.0 inclusive and 2.0 exclusive.
Because module 402 claims a dependency on version 1.5 or higher of
module "O," module 402 is able to use module 406 as a caller.
[0058] On the other hand, the second reverse dependency constraint
of module 406 (e.g., "permits implementer `this @ 1.6+`") may
prevent module 404 from using module 406 as an implementer because
module 404 claims a dependency on a version (e.g., "1.1") of module
"O" that is too low to meet the reverse dependency constraint. For
example, module 404 may not be allowed to implement module 406
because the interface provided by module 406 includes functions
that are not in the interface of the "O @ 1.1" module that module
404 claims to implement. Instead, module 404 may use the interface
of module 408, which has a reverse dependency constraint (e.g.,
"permits implementer `this @ [1.0, 2.0)`") that is satisfied by the
dependency of module 404.
[0059] FIG. 5 shows a flowchart illustrating the process of
facilitating the development and maintenance of a software program
in accordance with an embodiment. In one or more embodiments, one
or more of the steps may be omitted, repeated, and/or performed in
a different order. Accordingly, the specific arrangement of steps
shown in FIG. 5 should not be construed as limiting the scope of
the embodiments.
[0060] First, a role associated with a dependency of a consumer in
a software program on an interface is obtained (operation 502). The
role may identify the consumer (e.g., module, package, class) as a
caller and/or an implementer of the interface. In addition, the
role may be declared by the consumer or inferred from type
declarations in the consumer.
[0061] Next, a compatibility policy for the interface is obtained
(operation 504). As with the role, the compatibility policy may be
declared by the interface or inferred from changes in the interface
over time. Finally, the role and the compatibility policy are used
to manage use of the interface by the consumer in the software
program (operation 506). Role-based management of interaction
between consumers and interfaces is discussed in further detail
below with respect to FIG. 6.
[0062] FIG. 6 shows a flowchart illustrating the process of using a
role and a compatibility policy to manage use of an interface by a
consumer in accordance with an embodiment. In one or more
embodiments, one or more of the steps may be omitted, repeated,
and/or performed in a different order. Accordingly, the specific
arrangement of steps shown in FIG. 6 should not be construed as
limiting the scope of the embodiments.
[0063] Initially, the compatibility policy is used to characterize
a change in the interface (operation 602). For example, the
compatibility policy may specify a set of rules that guide the
creation of new versions of the interface based on changes to the
interface. The characterized change may be a binary-incompatible
change (operation 604) that removes an existing function from the
interface. If the change is characterized as a binary-incompatible
change, use of the interface by a caller is disabled (operation
606) to prevent the caller from calling the removed function. If
the change is not binary-incompatible, callers may continue using
the interface safely.
[0064] On the other hand, the characterized change may be a
source-incompatible change (operation 608) that adds a new function
to the interface. If the change is characterized as a
source-incompatible change, use of the interface by an implementer
is disabled (operation 610) to prevent the implementer from
attempting to implement the interface without implementing the new
function. If the change is neither binary-incompatible nor
source-incompatible, both callers and implementers may continue to
use the interface.
[0065] FIG. 7 shows a computer system 700 in accordance with an
embodiment. Computer system 700 includes a processor 702, memory
704, storage 706, and/or other components found in electronic
computing devices. Processor 702 may support parallel processing
and/or multi-threaded operation with other processors in computer
system 700. Computer system 700 may also include input/output (I/O)
devices such as a keyboard 708, a mouse 710, and a display 712.
[0066] Computer system 700 may include functionality to execute
various components of the present embodiments. In particular,
computer system 700 may include an operating system (not shown)
that coordinates the use of hardware and software resources on
computer system 700, as well as one or more applications that
perform specialized tasks for the user. To perform tasks for the
user, applications may obtain the use of hardware resources on
computer system 700 from the operating system, as well as interact
with the user through a hardware and/or software framework provided
by the operating system.
[0067] In one or more embodiments, computer system 700 provides a
system for facilitating the development and maintenance of a
software program. The system may include an SDK and a runtime
system. The SDK and runtime system may obtain a role associated
with a dependency of a consumer in the software program on an
interface. The SDK and runtime system may also obtain a
compatibility policy for the interface. The SDK and runtime system
may then use the role and the compatibility policy to manage use of
the interface by the consumer in the software program.
[0068] In addition, one or more components of computer system 700
may be remotely located and connected to the other components over
a network. Portions of the present embodiments (e.g., SDK, runtime
system, etc.) may also be located on different nodes of a
distributed system that implements the embodiments. For example,
the present embodiments may be implemented using a cloud computing
system that provides a module system for managing the life cycles
of software programs.
[0069] The foregoing descriptions of various embodiments have been
presented only for purposes of illustration and description. They
are not intended to be exhaustive or to limit the present invention
to the forms disclosed. Accordingly, many modifications and
variations will be apparent to practitioners skilled in the art.
Additionally, the above disclosure is not intended to limit the
present invention.
* * * * *