Figure 1. Summary of five LTSA layers.
LTSA Specification
Learning Technology Systems
Architecture
Date: 1998-05-21
From: Frank Farance, Joshua Tonkel
Title: Learning Technology Systems
Architecture (LTSA) Specification
Version: 4.00
URL: http://www.edutool.com/ltsa
Phone: +1 212 486 4700
Fax: +1 212 759 1605
E-mail: frank@farance.com, tonkel@farance.com
Notice: This document and its contents are Copyright © 1998 Farance Inc., Edutool Division
ABSTRACT
This Architecture Specification describes the high-level system design and the components of the Learning Technology Systems Architecture (LTSA). The LTSA specification covers a wide range of systems, commonly known as learning technology, computer-based training, electronic performance support systems, computer assisted instruction, intelligent tutoring, education and training technology, metadata, etc.. The LTSA specification is pedagogically neutral, content-neutral, and platform-neutral. The LTSA specification (1) provides a framework for understanding existing and future systems, (2) promotes interoperability and portability by identifying critical system interfaces, (3) incorporates a technical horizon (applicability) of a least 5-10 years while remaining adaptable to new technologies and learning technology systems. Many systems can comply with the LTSA specification (see section 10, Conformance) although they don't provide all the components, nor do they have the same organization.
Each section of this document begins with an Overview that provides a summary from the perspectives of: developer, administrator, teacher, and student. Section 1.3, Road Map, and the Index provide a directory of topics of interest. Section 11.2, Glossary, should be consulted for any unfamiliar or ambiguous terminology.
This document is being developed. The intended audience is: information technology, learning technology, and education. This the LTSA draft 4.00. Please return all comments to Frank Farance by Friday, 1998-07-03 21:00 UTC. See Section 12.2, Release notes for this document, and Section 12.5, Comments on this document, for instructions on delivering comments. This document is being developed in IEEE 1484 Learning Technology Standards Committee (LTSC) in close collaboration with Educom's Instructional Management (IMS) Project, the Aviation Industry CBT Committee (AICC), and the Department of Defense Advanced Distributed Learning (ADL) project.
TABLE OF CONTENTS
1. INTRODUCTION
This document presents the Learning Technology Systems Architecture (LTSA). The LTSA is a high level systems architecture and layering for learning technology systems, known as learning technology, computer-based training, electronic performance support systems, computer assisted instruction, intelligent tutoring, education and training technology, and so on. This document is a proposed architecture specification for the IEEE 1484 Learning Technology Standards Committee (LTSC) subject areas: reference model, learner model standards, learning objects, task model, course sequencing, tools/agent communication, ontologies, data interchange, course management, metadata, student identifiers.
This specification does not address the development systems (e.g., languages, authoring tools, operating systems) necessary to create the LTSA components.
The LTSA specification is pedagogically neutral, content-neutral, and platform-neutral.
(To the reader: The main points have been highlighted with green or underlining.)
The beginning of each section is an Overview that summarizes the section from the perspective of the developer (creates software and learning content), administrator (purchases systems, manages institutions and systems), teacher, and student.
This document is summarized by: purpose, process, results, key points, disclaimers.
This document is an architecture specification: the technical details can be used to specify systems as well as detailed systems components. Conformance to this architecture specification is non-exclusive: a system that conforms to the LTSA can also conform to other generic, cross-industry, industry-specific, national, regional, government, institutional, community, or standard specifications.
In general, the purpose of developing systems architectures is to discover high-level frameworks for understanding certain kinds of systems, their subsystems, and their interactions with related systems. An architecture isn't a blue print for designing a single system, but a framework for designing a range of systems over time, and for the analysis and comparison of these systems. By revealing the shared components of different systems at the right level of generality, an architecture promotes the design and implementation of components and subsystems that are reusable, cost-effective and adaptable.
The process used to develop this architecture consists of six steps:
Step #1: Gather requirements and desirables from all stakeholders.
Step #2: Gather all features, opportunities, and constraints from existing and emerging systems, products, services, and so on.
Step #3: Create abstractions (conceptual understandings) of the subject area. For example, a system that has three levels of abstraction might be constructed by (1) taking raw information and creating a low-level abstraction; (2) taking the low-level and creating a mid-level abstraction; (3) taking the mid-level and creating a high-level abstraction.
Step #4: Create higher abstractions until the number of components is reduced to a handful (e.g., 3-7 components). The number of abstraction levels equals the number of steps required to reduce the system to a handful of components.
At this point, the system has assumed the form of a candidate for a systems architecture.
Step #5: Re-implement the system downward from the highest level abstraction (most general concepts) based solely on the system's specifications and recreate its functionality, interfaces, and capabilities at the next lower level. From the example above: take the high-level abstraction and now re-implement the mid-level abstraction.
To be precise, the mid-level abstracted and generalized is the high-level; the high-level implemented via constraints is the mid-level, and so on. Note: "abstraction" and "implementation" are inverse operations.
Step #6: Incrementally and successively re-implement each lower level based on the level above.
The system has now been re-implemented based solely upon the candidate architecture and the implementation constraints. If the re-implemented system does not meet all the requirements and desirables, or does not encompass the existing and emerging systems (step #2), then the candidate architecture is not a systems architecture (go back to step #3), or the existing and emerging systems need to be re-evaluated (go back to step #2), or the requirements and desirables need to be re-evaluated (go back to step #1).
Otherwise, if the candidate architecture meets all requirements and desirables, and encompasses existing and emerging systems, then the candidate architecture is A systems architecture, not necessarily THE systems architecture -- there may exist several applicable systems architectures.
Figure 1. Summary of five LTSA layers.
The result of the architecting process: a new framework for understanding the system, with the important, common components and interfaces identified while still maintaining the system's functionality, capabilities, and connections to related systems. In other words, the new system behaves in the same way as the original system. This new conceptual framework, an architecture, allows for:
Thus, an architecture serves as a useful, general guide to understanding systems (e.g., learning technology systems) that are widely applicable and adapt over time.
The following are key points in the Learning Technology System Architecture:
Learning Technology Systems Architecture is not a white paper because (1) it is much more detailed than a typical white paper, and (2) a white paper is not used as a specification -- this specification can be used to measure conformance.
IMPORTANT: Many key terms appearing in this specification have currency in multiple areas of research and are subject to a variety of divergent interpretations. There is much overlapping and conflicting terminology in research on education, learning technology, and information technology. Thus, throughout this document key terms are to be understood solely as defined and used contextually, not as defined and used elsewhere. This document will be improved as terminology converges.
This specification consists of twelve major sections. The following is an overview of each section.
This document proposes, from an architecture and engineering viewpoint, five layers of architectural description that can be applied, widely and generally, to learning technology systems. This document is a proposed starting point for discussion, refinement, and acceptance of a standard architecture for learning technology systems. It is hoped that a refined, standard, interdisciplinary architecture will enable rapid, further development of:
The Learning Technology Systems Architecture has origins and inputs from several projects, which are listed in alphabetical order:
The authors thank the following people for providing substantial input and comments on present and previous versions of this document: Frank Belz, Brant Cheikes, Chris Dabrowski, Andy DiRienzo, Eddy Forte, Steve Griffin, Peter G. Hayes, Joe I. Holbrook, Mary Holland, Jack Hyde, William A. Imbriale, Mike Kendall, Keith Knightson, Bill McDonald, Tom Murray, Errol Naiman, Denis Newman, Neal Nored, Claude Ostyn, Mike Petit, Mark Resmer, Tyde Richards, Steve Ritter, William Rugolsky, Jim Schoening, Udo Schuermann, Kathy Sinitsa, Jim Spohrer, Bob Spengler, Dan Suthers, Peter Waegemann, David S. Warren, Dina Warren, Tom Wason, Tom Wheeler, Steve White.
The authors also thank the following organizations for their assistance: ADL, AICC, Educom, IEEE, IMS.
This chapter explains the methods and techniques used for analysis, synthesis, and refinement (i.e., development) of the Learning Technology Systems Architecture (LTSA). The section is not a tutorial -- there are many books and materials on systems engineering and architecture. This section is meant to be a brief overview of the process.
The methodology used to develop this architecture and its layering is based on the Yourdon systems analysis methodology. Text description, system notation, bus notation, and combinations are used to describe each of the layers.
The purpose of outlining the methodology is to reveal the rigorous development process in use -- this work was not "created in a vacuum". The methodology used to develop this architecture is based on common techniques used in software engineering for twenty years and for tens of thousands of systems. The methodology is "tried and true". At times, the methodology requires the application of "judgement calls", based on the experience of the architects and engineers.
Information is gathered on the topic (in this case, learning technology systems). There are three types of raw information:
Figure 2. Organize raw details into good examples, borderline examples, and bad examples.
When organizing information at a particular level of detail, it may be important to exclude certain information at that level. For example, when discussing the architecture of a house, it might be distracting and counterproductive to attend to plumbing issues; but plumbing issues might need to be addressed when drawing up blueprints.
Information exclusion might be better addressed by asking the question: what details obscure the main focus or main theme? A cartographer does not include all details when creating a map -- his/her judgement is based on the purpose and use of the map being created. This point may be illustrated by considering the diagramming of a web browser and web server as it is integrated into a larger system.
Figure 3. Essential vs. non-essential details for web browsers and servers. The choice
of which details to include/exclude is dependent on context and use.
In #1, the web browser and web server are diagrammed simply as: the web server transferring web content to the web browser. Of course, there are more details to this transaction, such as who initiated the transfer (#2, #3) and the source of files and programs (#4) that are served up to the client. But are these details necessary? If the analysis requires addressing those details now (e.g., incorporation of "push" and "pull" technology) then it may be appropriate to include those details. However, if the diagram can still be understood without the details, then the details should be excluded.
Excluding non-essential details greatly improves the readability, interpretation, analysis, and acceptance of diagrams.
IMPORTANT: Throughout the LTSA specification, the authors have made certain "judgement calls" on what to include and exclude for the sake of clarity, utility, and consensus.
Once the raw information is collected, the information is organized by levels of detail or "granularity". Information of coarser granularity (lesser detail) is organized as "abstractions" while information of finer granularity (greater detail) is organized as "implementations". There may be a need to identify several "refinement layers", i.e., not just an abstraction level and an implementation level but levels in between.
Information at the same level of detail is organized into function groupings called subsystems.
Miscellaneous information that is important, but does not describe a system boundary, a system interface, or system functionality ("what it does"), is kept separately and called "implementation constraints". For example, in a computer networking system the main purpose of the system is to transfer information, but cost and security might be implementation constraints.
For information at the same level of detail, each subsystem that is identified must have a clearly defined boundary. Subsystem boundaries are called "implementation-implementation" boundaries, e.g., an interface between two subsystems.
For information at different levels, each refinement layer must have a clearly defined boundary between its abstraction above and its implementation below. Refinement boundaries are called "abstraction-implementation" boundaries.
(NOTE: "abstraction-abstraction" boundaries refer to two abstractions that point to the same implementation. Currently, this technique is not necessary for this architecture specification.)
Three primary notation conventions are used throughout the LTSA: text description, system notation, and bus notation. The choice of notation is dependent on the nature of the subject. System notation is useful when there are a handful of subsystems, the functions or roles of each subsystem is well-defined, and the connections between subsystems are established and unchanging (see LTSA layers 1, 3, 4). Bus notation is useful when there are a large number of subsystems, the functions or roles are undefined or changing over time, and the connections between subsystems are dynamic or on-demand (see LTSA layer 5). Text description is useful when the subsystem boundaries are unclear, the subsystem boundaries are overlapping, or the system and bus notations are impractical (see LTSA layers 2 and 4).
The subsystems at the same level of detail are described via text description rather than a diagrammatic notation. Diagrammatic notations, typically, require firm subsystem boundaries and non-overlapping subsystems. If the boundaries of a subsystem are not well-defined, a textual description might be a useful placeholder until the boundaries are defined. If well-defined boundaries are not possible, a text description might be the only technique for describing the layer.
The LTSA layer 2, Human-Centered Features, uses a textual description.
The LTSA layer 4, Stakeholder Perspectives, uses a combination of systems notation and text description.
For subsystems at the same level of detail, each subsystem is connected, as appropriate, to other related subsystems. These connections define the flows between subsystems. Subsystem and flow analysis has been described in many good books, including several by Ed Yourdon. The following is a very brief summary of the notation.
The LTSA layer 1, Learner and Environment Interactions, uses system notation. Layer 1 consists of 2 processes and 1 data flow. One of the processes (learner) actually represents several subsystems (multiple students represent the collective learner).
The LTSA layer 3, System Components, uses system notation. Layer 3 consists of 4 processes, 2 data stores, and 10 one-way data flows, and 1 two-way data flow.
Figure 4. System notation uses components: process, stores, and flows. Processes can
manipulate data information, control information, or both. Stores can hold
data or control information. Flows can transfer data or control information.
Flows can be one-way or two-way.
Processes are represented by ovals. A subsystem is a (generic) process, i.e., something that is "alive" and able to transform its inputs into outputs. For example, a data transformation process transforms data inputs into data outputs. A data transformation process is represented by an oval drawn with a solid line. Information technology systems are mostly data transformation processes. Some information technology systems are called real-time systems. Real-time systems include both data transformations and control transformations. A control transformation process transforms control inputs into control outputs. A control transformation process is represented by an oval drawn with a dashed line. In practice, many processors combine a mixture of control inputs, control outputs, data inputs, and data outputs. A transformation that operates on a mix of both data and control is represented as a data transformation process, i.e., an oval drawn with a solid line.
Arrows are used to represent connections between the subsystems of the whole system. The arrows represent the flow of information, data or control, between subsystems.
Information that flows in a single direction from one subsystem to another is called a one-way flow. In the case of connecting multiple subsystems, a one-way flow has a single source (origin) OR a single sink (destination); a single source with multiple sinks or a single sink with multiple sources is considered a one-way flow. In considering data flows, it is important to distinguish between the direction of data transfer (data flow) and the person or system who initiated the data transfer (control flow). For example, when a person uses a web browser to call up a page from a web server, this transaction is notated as a data flow going from the server to the browser, i.e., a data output from the server connected to a data input of the browser, even though the person (browser) initiated the request. In other words, for web "push" and "pull" technology, the data flow is the same (i.e., a one-way flow from server to browser), but "pull" technology emphasizes the control flow (e.g., initiating the request) from browser to server, while "push" technology emphasizes the control flow from server to browser.
Information that flows in both directions between subsystems is called a two-way flow, e.g., telephone calls (two-way data flow), video conferencing (two-way data flow), network routing information (two-way control flow). In many cases, a protocol is used to organize the two-way flow of information between two subsystems.
A special case concerns the "updating" of information in a data store (e.g., a database) or a control store (e.g., event history). For example, when a record is updated in a database, typically, the record is retrieved, modified, and then stored. For notational purposes, there is no distinction between the creation of the original database record and its subsequent update (the modification of only certain fields): both creation and updating are notated as one-way flows into the data store.
The most common flow is the data flow, which represents data moving among two or more subsystems. A data flow connected to a subsystem represents data input (a one-way flow), data output (a one-way flow) or both (a two-way flow). Data is the unit of information, relative to the level of descriptive detail, that represents the main processing of the whole system (see Data vs. Control below). For example, in a subsystem that adds numbers (a calculator), the flow that supplies the numbers to be added (data entry) might be a data input flow; while the flow that emits the result of the calculation (output display) might be a data output flow. Data transferred in both directions is a data input/output (a two-way flow), e.g., data transferred over a modem.
The control flow represents inputs and/or outputs that control the processing of data among two or more subsystems. A control flow can be a control input (a one-way flow), a control output (a one-way flow), or both (a two-way flow). In the example above of the calculator subsystem that adds numbers, the signal to start calculating the sum (the ADD or "=" key) is a control input, and the signal to indicate that a calculation has overflowed (the ERROR light) is a control output. Control transferred in both directions is a control input/output (a two-way flow), e.g., the signaling that negotiates modem speed and quality when modems connect.
The choice of calling information data or control is somewhat arbitrary. For example, establishing a connection between a web browser and a web server might be described as control information from the perspective of web applications, but would be described as data information from the perspective of network routers. A guideline might be that if the information in question is involved in the main purpose of the system or the main inputs and outputs, it would be labeled as data information; if the information changes the processing of information, starts or stops processing, or starts or stops the flow of information, it would be labeled as control information.
A store holds information. A data store holds data information, e.g., a database. A control store holds control information, e.g., an event history.
Bus notation is used when the number of components is large, the functionality of the components is not pre-defined, or the connections between components is dynamic. Bus notation features: common naming, common control flow, non-homogenous data flow, and dynamic, on-demand connection.
The following diagrams illustrate bus notation.
Figure 5. An information bus uses a common namespace.
Each member of the bus has a unique name within the namespace of the bus. A "bus" implies a common, shared namespace.
Figure 6. An information bus uses a common control flow protocol among bus elements.
Each member of the bus uses the same protocol to request or respond to transactions. A "bus" implies a common control flow mechanism, e.g., starting and stopping transactions and/or the flow of information.
Figure 7. Data flows on information busses vary depending on sender and receiver.
The members of a bus can use different data flow protocols, but they use a common control flow protocols. A "bus" does not imply a common data protocol. Example: On the "internet bus", applications use IP (internet protocol) to initiate transactions and transfer data, but the data protocols can vary (e.g., HTTP over TCP, FTP over TCP, NFS over UDP).
Figure 8. Bus notation is used to represent dynamic, on-demand connections.
A bus is used to represent and implement dynamic, on-demand connections among the members of the bus. A bus does not imply "fixes" connections between specific members. Each transaction represents a dynamic connection among bus members.
Figure 9. Abstracting raw details to higher level abstractions. This diagram shows
three layers but, typically, there are more (the LTSA has five). The abstraction
process continues until the system is reduced to roughly 3-7 components.
Once information has been gathered, the conceptual understanding is described using one of more of the techniques above (other notations are possible, too). For example, a useful architecture for a given system may require three levels of abstraction: (1) take raw information and create a low-level abstraction; (2) take the low-level and create a mid-level abstraction; (3) take the mid-level and create a high-level abstraction, i.e., the architecture.
After each cycle of abstraction, a new, higher level abstraction is produced. Another output from the abstraction technique is a set of implementation constraints, i.e., features of the implementation (e.g., cost, performance) that are not represented in the functionality ("what it does") of the abstraction.
The abstraction technique (creating higher level abstractions, based on implementations and/or lower level abstractions) is repeated until the system is reduced to a handful of components, e.g., 3-7 components. The number of abstraction levels equals the number of steps required to reduce the system to a handful of components.
Other description techniques include the Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers, Wheeler.
Figure 10. Re-implementing the system. Each abstraction creates an implementation via
constraints. The system is re-implemented but architectures (high level
abstractions) may reveal new structures and/or create new systems not previously
conceived.
Once the highest-level abstraction is reached (the architecture specification), the system is then re-implemented on the basis of that abstraction (most general concepts). Re-implementing the system consists of implementing each abstraction layer in the context of implementation constraints. In other words, the system is built solely based on the specification. An "implementation" doesn't imply a functioning, physical system: an implementation might be a more detailed description of a higher level abstraction (concept).
If the newly implemented system (e.g., a high-level abstraction now built as a mid-level implementation) produces the same functionality, interfaces, services, and qualities (implementation constraints) as the original mid-level specification, then the iterative implementation process continues (success). If the newly implemented system does not match the requirements of the original mid-level specification, then the higher-level abstraction is incorrect or the implementation constraints are poorly defined (failure: go back and correct a previous step).
The iterative implementation process is continued until the last (lowest level) abstraction is implemented successfully, i.e., matches the original requirements and desirables of the existing and emerging systems in the data gathering step.
The purpose of re-implementing the system is to verify the correctness of the abstractions and the implementation constraints. When completed, this process validates the highest-level abstraction -- the architecture specification. In practice, an architecture specification is not completely re-implemented, but only the high-risk portions are prototyped. What is essential is the satisfaction of critical functional requirements (e.g., Is the high-level system still a learning technology system?) and/or important implementation constraints (e.g., Can the multimedia be delivered over the Internet? Can the student collaborate cost-effectively with other students?).
Figure 11. Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers,
and Wheeler.
One architecture analysis technique is to group technical issues into well-known information technology categories. The diagram above maps the LTSA, IEEE, IMS, AICC, and ARIADNE to the Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers, and Wheeler. The ARM can be useful for architecture analysis in areas outside of learning technology.
The methodology is merely a guideline -- sometimes there is no clear "right answer". Some "judgement calls" are required, based on the experience of the architects and engineers. The following are examples of "judgement calls" in the development of the LTSA. (See also 2.1 Information inclusion, and 2.2 Information exclusion.)
The Environment's affect on the Learning is shown by a one-way arrow, but why isn't the Learner's affect on the environment show (e.g., two-way arrow)? Learners do have an effect on their environment, e.g., a Learner's effect on a student teacher; the effect of the Learner's research that addresses the state of the art. While the Learner's affect on his/her Environment might be a part of the learning experience (e.g., teacher training, graduate school), these details are less important to the main theme of applying learning technology to learning experiences.
In the LTSA system components, the Locator Index is shown between System Coach and Delivery process, but the Locator Index is not shown between Delivery process and the Knowledge Library, and the Locator Index is required for retrieving Learning Content. Creating and emitting a Locator Index is a significant design issue and a significant "result" of the System Coach processing; thus, the System Coach is shown emitting a Locator Index. However, the Delivery system views the Knowledge Library simply as a database, so "requests" are not diagrammed -- only the "responses" to the requests are diagrammed.
In the LTSA system components, the flow between Delivery and Knowledge Library is one way, but clearly information flows both ways. The primary theme is the flow of Learning Content to the Delivery Process. The above paragraph identified one type of information (Locator Index) not diagrammed that flows in the opposite direction. There may be other information, too (e.g., electronic commerce, intellectual property rights management), but the one-way arrow still represents the main theme. IMPORTANT: A one-way arrow does not prohibit flow in the opposite direction or two-way flows at lower abstraction-implementation layers.
In the LTSA system components, both the "queries" (Query Indexes) to the Knowledge Library and their "responses" (Content Indexes) are diagrammed, but the "queries" to the Records Database are not diagrammed -- only the "responses" (System Coach extracting Learner's history) are diagrammed. Like above, there generation of Query Indexes is a significant step of the System Coach processing. The extraction of Learner's history is not a significant design issue for the System Coach so only the "responses" are diagrammed.
Abstracting, architecting, and implementing a system involves many iterations of "trying concepts" (abstractions) and "building them to verify that the abstractions work" (implementations). Many abstractions and implementations are possible. There is no single right answer, but there are wrong answers. Architectures are high-level abstractions that represent a range of systems, not a single system at a single point in time: architectures are general solutions that are adaptable over time.
Five refinement layers of architecture are proposed. They are applicable to a broad range of learning scenarios. These refinement layers are called, from highest to lowest levels:
Figure 12. LTSA abstraction-implementation layers.
The five abstraction-implementation layers identify design priorities, i.e., the ordering of most to least important. Intuitively, developers understand that, for example, the human features of learning technology systems (layer 2) have a more pervasive effect on system design than, for example, the particular multimedia format (layer 5) -- a localized, "swappable" feature. This section explains how the methodology was applied.
The five layers represent five independent areas of technical analysis. For example, it is possible to discuss an abstraction, e.g., the LTSA system components (layer 3), independently of an implementation, e.g., the bus protocols of an actual implementation (layer 5). In other words, even though layer 3 contains components such as "Evaluation" and "System Coach", there is no requirement for separable, identifiable components called "Evaluation" and "System Coach" in actual implementations.
The five layers of the LTSA help separate the "big picture" from the "details". The use of layers helps understand the problem "step by step".
The Learning Technology Systems Architecture is described in five successive refinement layers from highest to lowest. Each layer describes a system at a different level. The lower layers are implementations of the higher layers. The higher layers are abstractions of the lower layers.
This refinement layer focuses on the highest level functionality from an information technology perspective: the learner has new or different knowledge after a learning experience. In information technology, this is diagramed as one subsystem (environment) transferring information to the other subsystem (learner), i.e., interaction. The learner and environment interactions diagram is not intended to represent current theories of learning or a learning process. It represents the information technology issues of learning technology systems and is useful for common, well-understood software engineering analysis and design techniques. For the purposes of this architecture specification, the primary focus is information technology.
This refinement layer concerns the five most important design issues that result from involving human learners:
Human learners receive information via sensory inputs and/or physical interactions. Multimedia includes aural, visual, other sensory inputs, and physical interactions.
Human learners are unreliable in the sense that errors or limitations on the learner's part might delay or thwart the intended outcome of the learning experience (e.g., the learner forgets what was learned, learns the wrong thing, etc.). This motivates the need for some type of "feedback loop" that "drives" or "coaches" the learning experience. The "driver" of this feedback loop is responsible for improving the learning experience: maximizing desirable (intended) outcomes, minimizing undesirable (unintended) outcomes. The driver (System Coach) might be any combination of: student (see Glossary for distinction between student and learner in this context), parent, teacher, mentor, employer, institution, courseware developer, and so on.
Human learners are nomadic: they move from teacher to teacher (e.g., K-12), from institution to institution. A learner has more than one teacher over a lifetime of learning experience, so there is a need to transfer information about the learner, e.g., performance history and learning objectives, from one teacher to another (or, if the learner moves, from one institution to another). In addition, discovering the "best" learning strategy may require much investigation and analysis of the learner's performance over long periods of time. Inferences drawn from the analysis are used to influence the decision-making for adapting to the best learning style. Thus, the need to maintain a learner's performance history in a records database.
Human learners are unpredictable by virtue of their individual differences: unsurprisingly, there might be no "best" learning strategy for all. Nor is it surprising that human learners learn differently over time. This motivates the need for more than one strategy for "feedback loops". The ability to transfer learners (via common learner records database formats) from one teacher to another (or institution to another) makes a wider variety of learning strategies available to the learner and, thus, minimizes the effect of the unpredictable nature of human learners. A rich knowledge library helps support a wider variety of learning strategies, too, because the learner, student ("student" in contrast to "learner", see Glossary), parent, teacher, mentor, institution, etc., are able to pool a large library of knowledge so as best to serve the learner's needs.
Human learners can be aware of their own "best" learning styles. An learner does not always respond best to the same learning strategy over his/her lifetime of learning experience. Thus, learning styles may be varied to serve the learner's (or teacher's, or institution's) needs. It may be impractical or inefficient for the teacher (or institution) to dictate the "best" learning style, even if the teacher (or institution) has detailed records of the learner's performance. In some cases, the learner might be able to provide better insight on the style or strategy that works best for him or her. Likewise, the learner shouldn't always dictate the style or strategy. Thus, provision should be made to enable learners and other stakeholders (parents, teachers, mentors, employers, institutions, etc.) to negotiate (two-way communication) the optimum style or strategy so that the learning experience can best adapt over time.
In summary: Human learners require sensory input and/or physical interactions to receive information. The unreliability of human learners motivates the need for a "feedback loop" to maximize desirable learning experiences and minimize undesirable learning experiences. A history of learner performance is required because the best learning strategies may only be discovered after long periods of observing the learner's behavior. Also, learner performance information is necessary to support the transition of learners though different institutions, courses, teachers, and so on. A wide and rich knowledge library is required to support many learning strategies and to accommodate the differing needs of individuals (some learners learn best by reading, some by discovery, some by collaboration, some via tutors, etc.). Negotiated learning styles allow all participants and stakeholders to adapt to the needs of the learner, student ("student" in contrast to "learner"), parent, teacher, institution, employer, etc., because the "best" learning style can vary over time for the participants and stakeholders.
The LTSA identifies four processes: Learner, Evaluation, System Coach, and Delivery process; two stores: Records Database and Knowledge Library; and seven information flows among the components: Behavioral observations, Assessment information, Performance information, Query Index, Content Index, Locator Index, Learning Content, Multimedia, Learning Style.
Briefly, the overall flow has the following form: (1) the learning style or strategy is negotiated among the learner and other stakeholders; (2) the learner is observed and evaluated; (3) the evaluation produces assessments and/or performance information; (4) the performance information is stored in the learner history database; (5) the system coach reviews the learner's assessment, past performance history, and, possibly, future learning objectives; (6) the system coach searches the knowledge library, via query and content indexes, for appropriate learning content; (7) the system coach extracts the locator indexes from the available content indexes and passes the locator indexes to the delivery process, e.g., a lesson plan; (8) the delivery process extracts the learning content from the knowledge library, based on locator indexes, transforms the learning content to an interactive multimedia presentation to the learner.
In a given learning situation, there is not necessarily a one-to-one correspondence between system components and individuals. An individual might represent more that one system component in a given learning situation, e.g., the individual who represents the Learner might also represent the System Coach in a self-paced learning environment. Likewise, more than one individual might represent a single system component in a given learning situation, e.g., the Learner might be represented by several individuals learning collaboratively or as a team.
Although a single set of components is described, there might be several different kinds of learning experiences occurring simultaneously in a given learning situation. For example, a course offered jointly by the mathematics and computer science departments may foster two different kinds of learning experience, yet there is only one "physical" course that the learner attends. Another example would be the student teacher in the classroom: the "learners" are learning (through their own learning experiences), and the teacher is a "learner", too (a different learning experience).
In Section 4, over forty stakeholder perspectives are formulated and reviewed from the standpoint of the LTSA. The list of perspectives isn't exhaustive. The goal is (1) to verify the validity of the LTSA components in significant systems, stakeholders, or industries, (2) to discover which LTSA components are emphasized and de-emphasized in different systems, and, (3) to determine priorities among lower-level design issues.
The stakeholder perspectives require a separate refinement layer because this layer of granularity addresses the design issue: which perspective, view, or subset is relevant to the lower-level design.
The major areas of operational components are identified via bus notation and information busses: protocols, interchange methods, processes, data stores, control flow, and human interfaces. Knowing which busses and protocols are in use can help increase the understandability of a system, but common busses and protocols don't imply interoperability, e.g., just because applications use TCP/IP or XML, it does not mean that they can interoperate among themselves.
The top refinement layer of the LTSA is a very generalized architecture refinement layer called "Learner-Environment Interactions" (see below). IMPORTANT: There is often much confusion about this level of abstraction. The aim at this level is to view the system from an information technology perspective (e.g., in terms of the flow of information). Many readers misread this refinement layer as a description of a theory of learning. This is not a diagram of any theory of learning. The purpose of describing learning technology at this level of abstraction is to relate it to the software engineering methodology to create lower levels of abstraction.
The top layer describes the basic purpose of learning technology systems: learning experiences that involve learners interacting with their environment.
For the non-engineer reader, it is best to skip this section. This section is necessary for technical analysis: there must be some starting point for abstraction-implementation layers. However, the diagrams and notation often confuse non-engineers because they believe these diagrams represent pedagogy, theories of learning, etc. -- they don't. The diagrams are helpful for simply answering the engineering analysis question: what is the main information flow?
Figure 13. The learner's perspective of the learning environment.
The Learner-Environment Interactions diagram only represents the Learner and the Environment from a systems engineering perspective of information technology, i.e., this diagram doesn't portray current research on theories of learning. The reason for using this diagramming technique is to simplify certain engineering aspects of technology design. For example, one theory of learning might consider the learner in an environment that causes changes in the learner's mental states that result in the learner having new or different knowledge. This is analogous to computer networks: data doesn't actually flow from system to system, but events occur (network protocols) that cause changes in the computer system's state (i.e., the computer is an event driven state machine that has subcomponents organized as smaller state machines, e.g., a process or a database server), and these changes in the system's state result in its having new or different data. Thus for this part of the problem, the focus is on the overall view of information flow and the system is diagramed as a one-way arrow (flow) of Interactions from the Environment to the Learner. Of course, the implementations of concepts (lower level abstractions or systems themselves) will focus on pedagogical or other technical issues.
Figure 14. Learner-Environment Interaction System diagram. Note: Collaboration among
the students is internal to the collective Leaner.
The Learner (process) represents an abstract learner, e.g., a student, several students working collaboratively, or members of a team operating in different roles.
IMPORTANT: Collaboration among students is internal to the collective Learner. An analogy is a distributed database system: several individual databases "collaborate" to give the appearance of a single database. The LTSA notion of student collaboration, i.e., internal to the Learner rather than as a separate component, is an important simplifying feature of the LTSA.
The Environment (process) represents the environment that the Learner interacts with. The Learning Interactions (flow) represents the learning experiences.
This refinement layer represents the significant design issues of implementing a Learning-Environment Interaction System involving human Learners. From an information technology perspective, human learners impose significant design constraints -- their effects are pervasive. For example, humans are unreliable and unpredictable receivers of information. Had computers been the receivers of information, the unreliability effects could be localized (via error detection and correction), the unpredictable effects might be non-existent, and the design priority of the features of this layer would be much lower in the abstraction-implementation layers.
The human-centered features have a pervasive effect on the design. Thus, human-centered features become one of the higher abstraction-implementation layers.
The high priority given to human-centered features, their explicit layering, and notation are probably not familiar to non-engineering readers. Simply put, humans are not computers and every design issue concerning humans adds more "design risk" to the system. An analogy is building a house on unstable ground: typically foundation design is not a difficult or risky task for house building (i.e., a lower design priority), but for complex foundations the design risk is higher so the design priority should be higher -- in fact, if the design risk is high enough, the design of the rest of the house may be affected by the design of the foundation. The same is true for learning technology systems: the nature of human learning has significant "design risk" (it affects the design of the rest of the system) so human-centered features should have high design priority (LTSA layer 2).
Figure 15. Learner is a "faulty" information receiver. Learner in not a computer.
The most significant features of designing a learning technology system for humans are:
An important feature, but not a design issue at this level, is that a single human can play several roles (e.g., in addition to the role as Learner, the student can also perform Evaluation and the student can be the Records Database) and several humans can play a single role (e.g., several students collaborating as a collective Learner; the parent and teacher suggesting Learning Styles on behalf of the Learner).
Another important feature is that several learning experiences may be occurring simultaneously, even though a single set of components is described. For more information, see section 7.6, Multiple, parallel, and/or recursive components.
5.2_Transferring_information<--A>">
Figure 16. Transferring information to the Learner via sensory input and/or physical
interactions.
The starting point of the LTSA is the Delivery of information, via multimedia, to the Learner. Typically, multimedia includes aural and visual information, but multimedia may include other sensory information and/or physical interactions. Note: From this perspective, this portion of learning technology systems is no different than entertainment systems. The difference between entertainment systems and learning technology systems is the coaching and "feedback loop" that measures (Behavior and Evaluation) the effect of the experience (e.g., Delivery of Multimedia) and chooses appropriate learning content (System Coach, Query Index, Content Index, Knowledge Library, Locator Index) based on this measurement (Assessment and Performance information) for future learning experiences (e.g., Delivery of Multimedia).
Figure 17. The feedback and coaching loop.
Feedback, coaching, and Learner interaction are necessary to maximize desirable learning experiences and minimize undesirable learning experiences. Learner interaction may be desirable for other reasons, such as making the learning experience more enjoyable, motivating the Learner, and improving the teacher's skills.
The Behavior of the Learner, the Evaluation of that Behavior, and the Assessment that is produced determine where the student "is at". This is similar to feedback control systems where the system coach needs to know the current position (absolute position or relative to a desired position) of the object being controlled.
The System Coach determines "current position" from the Assessment. Based on the "current position", the System Coach determines the appropriate "action" (Delivery of Learning Content, etc.) to achieve the desired "target" (pedagogical objectives). The System Coach sends Locator Indexes (references to lessons, experimentation tools, suggestions, etc.) to the Delivery system.
Feedback loops can recover for errors (in this case, in human response to the learning experience) or can coach, motivate, and direct towards targets and goals. Of course, this oversimplifies many learning technology systems (and human learning itself), but feedback loops represent significant portions of learning experiences, determining what the Learner has learned and changing the Delivery of Learning Content (e.g., lesson plan) to achieve the desired objective.
Figure 18. Records Database is necessary for a lifetime of learning.
Learners are nomadic and, typically, change teachers frequently, i.e., a single Learner does not have a single teacher for his/her lifetime of learning. A primary reason for a Records Database is "handing off" Learners to other teachers and/or institutions.
Another significant design issue is that Learners learn over long periods of time. It may take long periods of interaction with the Learner to determine the best strategy. Typically, there will be more than one teacher associated with a Learner's lifetime of learning experience, so Performance information is stored in Records Databases for the purpose of communicating to other teachers so that each can "pick up where the last left off", i.e., the next teacher minimizes the amount of observation (of Behavior) and Evaluation needed to determine where the student "is at". Of course, Learners, students (in contrast to Learners, see Glossary), parents, and employers are interested in Performance information of their history (Records Database) because they can influence the learning experience, too.
In summary, a Records Database containing Performance information supports the long-term analysis of student performance and supports better "hand-offs" from one teacher (or learning technology system) to another. A Records Database is commonly used to store information about the past (Learner history), but the Records Database may be used to store information about the present (e.g., Assessments, current position) and the future (e.g., Learner or employer objectives).
Figure 19. A rich Knowledge Library is necessary for varying Learners.
A Knowledge Library is necessary to support diverse learning capabilities, strategies, and styles. If a Learner is having problems with a particular lesson, an alternate lesson plan may be used to meet the Learner's needs. If the lesson is going "too fast", going slower might suffice, while other problems are best solved by varying the style of presentation of the material or by varying the material itself, e.g. adjusting the degree of difficulty. In this case, the Knowledge Library supports different learning capabilities by having a variety o choices of Learning Content to meet the varying needs of Learners. With detailed Performance information, a sophisticated Records Database, inference systems and a rich Knowledge Library, the System Coach has a wide range of learning experiences, i.e., Learning Content, to choose from, such as lessons, interactions, suggestions, tutors, experiments, resources, and so on.
In summary, the unpredictability of the learning experience requires a significant Knowledge Library to support varying learning styles and strategies.
Figure 20. Both Learner and system may have insight to best learning experience.
The Learner himself/herself may interact with the System Coach to communicate Learning Styles. The negotiation may be one-way (also known as an "assertion" or an "inquiry", e.g., Learner has sole responsibility for advising, or the System Coach has sole responsibility for directing), two-way (e.g. Learner selects choices from those presented by System Coach), or involve other participants, such as parent, employer, mentor, institution, or courseware developer. Depending on the role, the parent, employer, or institution may act on behalf of the Learner or the System Coach.
The following diagrams review the five steps to developing the LTSA system components. The LTSA system components are solely based on the human-centered features.
Note: The development of the LTSA system components is based solely on the "axioms" of human-centered learning: the five human-centered features. There are no additional components added outside the ones required for human-centered learning, thus, the LTSA is a minimalist approach to system architecture.
Figure 21. Step #1: Transferring information to Learner via sensory input and/or
physical interactions.
Figure 22. Step #2: Humans are unreliable Learners so feedback and coaching loops
are necessary.
Figure 23. Step #3: Records Databases are necessary for a lifetime of learning and
long-term analysis of Learner history.
Figure 24. Step #4: Rich Knowledge Library for diverse and unpredictable capabilities
of Learners.
Figure 25. Step #5: Learner has insight into his/her learning capabilities.
Humans can play one or more simultaneous roles in a learning technology system, i.e., not all components are completely automated. Additionally, infrastructure may have multiple purposes. The following is a brief sampling of some possible mappings:
The learner and environment interactions, as represented by the Learner-Environment Interactions System abstraction (concept) and implemented via the constraints of human-centered systems, result in a system that reflects important design constraints of human learning:
All LTSA components (Learner, Behavior, Evaluation, Assessment, Performance information, Records Database, Learning Content, Query Indexes, Content Indexes, Locator Indexes, Knowledge Library, Delivery system, interactive Multimedia, Learning Styles) reflect the design constraints of implementing a human-centered learning technology system.
This section describes the processes, flows, and stores of the Learning Technology Systems Architecture. Processes are described in terms of boundaries, inputs, process (functionality), and outputs. Flows are described in terms of connectivity (one-way, two-way, static connections, dynamic connections, etc.) and the type of information across the flow. Stores are described by the type of information stored, and by search, retrieval, and updating methods.
As elsewhere in this specification, the descriptions are to be understood as specifying general components, and the purpose of the notation is to identify generic features. Most actual, physical implementations of learning technology systems will not fit these component boundaries exactly, but represent implementation variations. For example, many commercial courseware delivery systems combine portions of the Evaluation, Delivery, and System Coach processes into a single session presentation tool. This combination is an implementation efficiency, but conceptually, the components are separate, and some implementations keep the components separate. In this respect these systems resemble automobiles, in which the steering and power management are located together in front of the driver, but are conceptually separate; and some implementations separate the components (e.g., long fire trucks).
Each LTSA system component is described. Processes and stores are described by their functionality and their interfaces. Flows are described by their connectivity (the components they connect) and the protocols or formats of information across the flow.
Each LTSA system component is described. This section contains the technical describe of the critical interfaces for learning technology systems. System and component interoperability is greatly enhanced by the identification and establishment of the critical interfaces.
This section describes the technical details of each LTSA system component. This section is necessary for precise technical specification, but the teacher and student readers may skip this section.
Figure 26. The LTSA system components.
The LTSA system components are:
Throughout this specification the names of the LTSA components will be capitalized in order to distinguish them from the corresponding generic nouns, e.g., "Learner" (LTSA) vs. "learner" (generic). In some cases, the word "process", "flow", or "store" will be used to clarify the usage of the term (e.g., "Evaluation process" versus "evaluation").
Figure 27. Learner (process): The abstraction of the human student.
The Learner process is an abstraction of a human student. The Learner may represent a single student, a group of students learning individually, a group of students learning collaboratively, a group of students learning in different roles, and so on.
The Learner receives a Multimedia presentation and their Behavior is observed. At this level of abstraction, the Multimedia presentation and observable Behavior are diagramed separately. However, actual implementations will usually combine these features into one or more Human Interface modules (e.g., windowing systems), Session Presentation modules (e.g., web browser), tutoring tools (e.g., specialized applications), experimentation and discovery laboratories, and so forth.
The Learning Style is negotiated with the System Coach.
Figure 28. Learning Styles (data flow): All interested parties contribute to learning
style.
The Learner, the System Coach, and their surrogates negotiate Learning Styles. In addition to the Learner (student), the parent, teacher, mentor, employer, and/or institution may participate in the negotiation of learning style.
Learning Styles negotiation has much similarity and commonality with cultural adaptation and accessibility for people with physical (e.g., blind, deaf) and cognitive limitations.
Figure 29. Behavior (data flow): The coding and encoding of Learner's actions.
The Behavior flow is a transmission of Learner behavior, coded then encoded, from the Learner to the Evaluation process. At the Evaluation process, the Behavior is framed in the appropriate context by matching the Learning Content to the range of Behavioral responses.
Behavior coding is how Behavior information is organized, e.g., key clicks, mouse clicks, voice response, choices, written responses. Codings represent the Learner's behavior independently of Learning Content. For example, a "control wheel" (a rounded wheel) might be used for airplane flight simulation and automobile driving simulation. A common behavior coding might be the number of degrees that the wheel moved. However, the wheel moving X degrees has a substantially different meaning in flight simulation than in driving simulation.
Behavior encoding is how Behavior information is represented as bits and bytes. For example, a behavior coding such as key clicks might have several encodings: ASCII octets or scan codes might be different encodings. A single encoding such as ASCII might be used for different codings: written responses and mouse clicks both might be encoded in ASCII.
Figure 39. Evaluation (process): The processing of Behavior to produce Assessment and
Performance information.
The Learner's observable Behavior is an input to the Evaluation process. The Evaluation process produces Assessment information ("where the Learner is at") and sends the Assessment information to the System Coach. The Evaluation process creates Performance information that is stored in the Records Database.
The Evaluation process uses the Learning Content to provide context to the Learner's Behavior to determine the appropriate Evaluation. For example, a Learner is expected to select from a multiple choice question and the correct answer is "#2", but the Evaluation process has no context that the keystrokes "2" (or "#2" or "two") are the correct answer -- the Learner Content provides the context ("the correct answer is #2") to correlate the correct Behavior (e.g., the keystroke "2").
Figure 31. Performance (data flow): Output from Evaluation, to be stored as Learner
history information in Records Database.
The Evaluation process sends Performance information to the Records Database, e.g., "question 17, answered correctly, 85 seconds elapsed". The granularity is unspecified for the emitted Performance information, e.g., the Evaluation process can emit Performance information as much as every mouse click or as little as every semester.
Figure 32. Records Database (data store): Storage and retrieval of Performance information
of the past (history), present (bookmarks, current Assessment), and future
(objectives).
The Records Database stores Performance information. Performance information can come from both the Evaluation process (e.g., grades on lessons) and the System Coach (e.g., certifications). The Records Database holds information about the past (e.g., Learner history records), but can also hold information about the present (e.g., current Assessments for suspending and resuming sessions) and the future (e.g., pedagogy, Learner, or employer objectives).
Figure 33. Performance (data flow): System Coach retrieves Learner's Records, returned
as Performance information.
The System Coach requests and receives Performance information from the Records Database. Typically, historical information is retrieved, but current information (e.g., "bookmarks" for resuming sessions) and future information (e.g., template of future academic objectives) may be retrieved.
Figure 34. Performance information (data flow): System Coach stores Assessments and
certifications in Learner's Records Database.
The System Coach stores Performance information, such as Assessments and certifications, in the Records Database. The System Coach may store "bookmarks" as Performance information for saving the Learner's session and resumption at some future time.
6.10_Assessment<--A>">
Figure 35. Assessment (data store): Output from Evaluation, represents Learner's "current
state".
Assessments are emitted from the Evaluation process and describe "where the Learner is at". The System Coach receives Assessments and uses them to determine or suggest, in part, future learning experiences.
Figure 36. System Coach (process), Part 1: Negotiates Learning Style for optimum learning
experience.
Step #1: The System Coach negotiates the Learning Style with the Learner. A learning style is chosen by either the Learner (one-way negotiation, i.e., an assertion or inquiry), the System Coach (one-way negotiation, i.e., an assertion or inquiry), both the Learner and System Coach (two-way negotiation), or an external authority (e.g., parent, teacher, institution, courseware developer).
Figure 37. System Coach (process), Parts 2 and 3: Receives current Assessment from
Evaluation. Searches and retrieves Performance information relevant to the
current learning experience.
Steps #2 and #3: The System Coach receives the current Assessment from the Evaluation process and Performance information from the Records Database to support the decision-making process.
Figure 38. System Coach (process), Part 4: Searches Knowledge Library via Query
Indexes for appropriate Learning Content. Knowledge Library returns "found"
Content Indexes (metadata) that match the Query Index.
Step #4: Based on the current Assessment and historical Performance information, the System Coach sends Query Indexes to the Knowledge Library to search for appropriate learning materials. The Knowledge Library returns Content Indexes, i.e., a list of Locator Indexes that match the search query.
Figure 39. System Coach (process), Part 5: Extracts the Locator Indexes (e.g., URLs)
from the "found" Content Indexes (metadata). Sends the Locator
Indexes to the Delivery process to direct the learning experience.
Step #5: The appropriate Locator Indexes (e.g., a lesson plan) are sent to the Delivery process.
Figure 40. Query Indexes (data flow): The "search request" when looking for
appropriate Learning Content in the Knowledge Library.
The System Coach sends Query Indexes to the Knowledge Library to search for content that is appropriate for the Learner. The Query Indexes specify search criteria based on, in part, Learning Style, Assessment, and Performance information.
Figure 41. Knowledge Library (data store): A database that represents the "knowledge"
of the learning experiences. The "knowledge" is represented as
presentations, tutorials, experiments, etc..
The Knowledge Library stores knowledge, presentations, tutorials, tutors, tools, experiments, laboratories, and other learning materials as resources for the learning experience. The Knowledge Library may be searched by Query Indexes. The matching information is returned as Content Indexes, i.e., a set of content tags that are, conceptually, "card catalog" entries (also known as "metadata"). The locator Indexes (conceptually, "call numbers" on the bindings of the "books in the digital library", e.g., URLs) are extracted from the content indexes. The locator Indexes are used by the Delivery process to retrieve Learning Content. It is unspecified who initiates the transfer of Learning Content (e.g., the Learner, the System Coach, or the Delivery process). For example, a query on a topic in chemistry (specified as a Query Index) might return a set of Content Indexes that include a laboratory experiment simulating the behavior of solids, liquids, and gases, a presentation on Boyle's Law, a bibliography or related materials, a tutorial, a chemistry tutor in the same city as the Learner, and an ontology (a conceptual model of the subject represented as generic Learning Content) for temperature.
Figure 42. Content Index (data flow): Represents "card catalog" information
about Learning Content in the Knowledge Library. Content Indexes are also
known as "metadata".
Content Indexes are the result of searches of the Knowledge Library, as directed by Query Indexes. The Content Indexes are also known as metadata. Metadata is best known in web content for facilitating searches. However, web content metadata is inadequate for learning content because learning content requires more search criteria (e.g., pre-requisites, co-requisites, learning style) than what i