+This allows the addition of behaviours:
+for example, @code{cffi} adds support of special FFI description files
+to interface with C libraries and of wrapper files to embed C code in Lisp;
+@code{abcl-jar} supports creating Java JAR archives in ABCL;
+and @code{poiu} supports for compiling code in parallel using background processes.
+
+This chapter deals with @code{component}s and @code{operation}s.
+
+A @code{component} represents an individual source file or a group of source files,
+and the things that get transformed into.
+A @code{system} is a component at the top level of the component hierarchy.
+A @code{source-file} is a component representing a single source-file
+and the successive output files into which it is transformed.
+A @code{module} is an intermediate component itself grouping several other components,
+themselves source-files or further modules.
+
+An @code{Operation} represents a transformation that can be performed on a component,
+turning them from source files to intermediate results to final outputs.
+
+A pair of an @code{operation} and a @code{component} is called an @code{action}.
+An @code{action} represents a particular build step to be @code{perform}ed,
+after all its dependencies have been fulfilled.
+In the ASDF model, actions depend on other actions.
+The term @emph{action} itself was used by Kent Pitman in his old article,
+but was only used by ASDF hackers starting with the ASDF 2;
+but the concept is ubiquitous since the very beginning of ASDF 1,
+though previously implicit.
+
+Then, there are many @emph{functions} available
+to users, extenders and implementers of ASDF
+to use, define or implement the activities
+that are part of building your software.
+Though they manipulate @code{action}s,
+most of these functions do not take as an argument
+a reified pair (a CONS cell) of an operation and a component;
+instead, they usually take two separate arguments,
+which allows to take advantage of the power CLOS-style multiple dispatch
+for fun and profit.
+
+There are many @emph{hooks} in which to add functionality,
+by customizing the behavior of existing @emph{functions}.
+
+Last but not least is the notion of @emph{dependency} between two actions.
+The structure of dependencies between actions is
+a directed @emph{dependency graph}.
+ASDF is invoked by being told to @emph{operate}
+with some @emph{operation} on some toplevel @emph{system};
+it will then @emph{traverse} the graph and build a @emph{plan}
+that follows its structure.
+To be successfully buildable, this graph of actions but be acyclic.
+If, as a user, extender or implementer of ASDF, you fail
+to keep the dependency graph without cycles,
+ASDF will fail loudly as it eventually finds one.
+To clearly distinguish the direction of dependencies,
+ASDF 3 uses the words @emph{requiring} and @emph{required}
+as applied to an action depending on the other:
+the requiring action @code{depends-on} the completion of all required actions
+before it may itself be @code{perform}ed.
+
+Using the @code{defsystem} syntax, users may easily express
+direct dependencies along the graph of the object hierarchy:
+between a component and its parent, its children, and its siblings.
+By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
+Most common operations, such as @code{load-op}, @code{compile-op} or @code{load-source-op}
+are automatically propagate ``downward'' the component hierarchy and are ``covariant'' with it:
+to act the operation on the parent module, you must first act it on all the children components,
+with the action on the parent being parent of the action on each child.
+Other operations, such as @code{prepare-op} and @code{prepare-source-op}
+(introduced in ASDF 3) are automatically propagated ``upward'' the component hierarchy
+and are ``contravariant'' with it:
+to perform the operation of preparing for compilation of a child component,
+you must perform the operation of preparing for compilation of its parent component, and so on,
+ensuring that all the parent's dependencies are (compiled and) loaded
+before the child component may be compiled and loaded.
+Yet other operations, such as @code{test-op} or @code{load-fasl-op}
+remain at the system level, and are not propagated along the hierarchy,
+but instead do something global on the system.