Đồ án Thiết kế hệ thống quản lý học LMS

ưa tới phía học viên. Hơn một asset có thể được tập hợp lại để xây dựng các asset khác (Chẳng hạn như asset là trang HTML có thể là tập hợp của các asset khác nhau như ảnh, text, audio, và video. Trên hình vẽ biểu diễn một loạt các asset khác nhau: file audio WAV, file Audio MP3, các hàm javascript, ảnh JPEG, ảnh GIF, một đoạn HTML, trang Web, đối tượng Flash, tài liệu XML. Asset có thể có thể được mô tả bởi asset Meta-data cho phép tìm kiếm và phát hiện trong các kho chứa, do đó tăng tính sử dụng lại. SCO (Sharable Content Object). Một SCO là một tập hợp của một hoặc nhiều asset biểu diễn một tài nguyên học tập có thể tìm kiếm và hiển thị sử dụng SCORM RTE để trao đổi thông tin với LMS. Sco là tài nguyên học có thể theo dõi được bởi hệ quản trị học thông qua môi trường runtime. Sự khác biệt duy nhất giữa SCO và asset là SCO trao đổi thông tin với LMS sử dụng IEEE ECMAScript API. Để hiểu rõ hơn hãy xem hình vẽ dưới đây: Trên hình vẽ chỉ ra được sự khác biệt của SCO với asset. Bên tay trái chỉ ra SCO là tập hợp của các asset khác nhau. Điểm khác biệt là nằm ở khung bên tay phải. Khung đó mô tả quá trình SCO trao đổi thông tin với LMS. Đầu tiên, SCO tìm LMS cung cấp đối tượng API. Sau đó, SCO sử dụng đối tượng tìm thấy gọi phương thức Initialize() để khởi tạo phiên làm việc với LMS. Nếu cần SCO có thể dùng các phương thức API GetValue, SetValue để lấy hoặc thiết lập các giá trị cần thiết. Cuối cùng, SCO kết thúc phiên trao đổi thông tin với LMS thông qua phương thức Terminate(). Cũng như asset, SCO có thể được mô tả bởi siêu dữ liệu của SCO nhằm phục phụ cho việc tìm kiếm và phát hiện được trong các kho lưu trữ tài nguyên học tập với mục đích tăng cường tính tái sử dụng của SCO. SCO là đơn vị nội dung học nhỏ nhất có tính chủ đề nên việc được tái sử dụng cho các mục đích học khác nhau là điều hoàn toàn có thể. SCORM không quy định kích thước cụ thể của một SCO. Người phát triển nội dung sẽ quyết định kích cỡ này dựa trên mục đích tái sử dụng của SCO. Như đã trình bày ở hình vẽ trên, SCO phải tuân theo các quy định xác định trong SCORM RTE. SCO phải có các công cụ cần thiết để tìm LMS cung cấp API và gọi tối thiểu 2 phương thức Initialize(), Terminate(). Các hàm khác có thể được gọi nhưng chỉ là tuỳ chọn. Việc tuân thủ các yêu cầu bắt buộc SCO phải tuân theo các quy định trong SCORM RTE khi tham gia vào hệ LMS đem lại lợi ích sau: LMS hỗ trợ SCORM RTE có thể tìm và hiển thị SCO và theo dõi chúng bất kể chúng được tạo ra bởi nhà cung cấp nào. Bất kỳ LMS nào hỗ trợ SCORM RTE có thể kích hoạt và theo dõi các SCO bắt đầu khi nào và kết thúc khi nào. Bất kỳ LMS nào hỗ trợ SCORM RTE có thể phát hiện và hiển thị các SCO theo cùng một cách giống nhau. Gói nội dung (content package). Gói nội dung là gói biểu diễn một đơn vị học tập. Nó có thể là một phần của khoá học, một khoá học, hay là tập hợp nhiều khoá học khác nhau và được phân phối một cách độc lập. Một gói phải có khả năng tồn tại một mình, tức là, nó phải chứa các thông tin cần thiết để LMS có thể sử dụng được nội dung của gói truyền tải tới học viên khi được yêu cầu. Cấu trúc gói nội dung cung cấp cho người tạo giáo trình một phương thức tập hợp các tài nguyên học thành một đơn vị học trình, module hay một khoá học. Cấu trúc gói nội dung có thể coi như một sơ đồ cho việc duyệt các tài nguyên học trong một khoá học. Khi học viên tham gia vào một khoá học thì LMS sẽ truyền tải nội dung học theo một thứ tự đã được định trước của người tạo ra khoá học này. Để biểu diễn cấu trúc nội dung chúng ta cần: Sự phân cấp nội dung: đó là một cách biểu diễn dạng cây, cho phép nhóm logic các thành phần tài nguyên học. Thường thì đây là trình tự ngầm định mà người tạo giáo trình muốn học viên phải tuân theo khi duyệt khoá học. Siêu dữ liệu hướng văn cảnh: khi tạo các đơn vị kiến thức thì người tạo giáo trình thường tạo các siêu dữ liệu để mô tả tài nguyên học, các siêu dữ liệu này độc lập về văn cảnh. Nhưng khi nhóm các tài nguyên học này lại thành một tập hợp ta cần các siêu dữ liệu khác để mô tả nó trong một văn cảnh. SCORM cung cấp các siêu dữ liệu cho mục đích này. Sắp thứ tự và duyệt: cung cấp thông tin cho hệ LMS biết cần phải kích hoạt tài nguyên học nào và vào khi nào. Sắp thứ tự đơn giản nhất là tuần tự qua các đơn vị bài học, phức tạp hơn thì dựa vào các tài nguyên học đã được hoàn thành trước đó của học viên. Một gói nội dung bao gồm hai phần chính: Tài liệu XML mô tả tổ chức của gói nội dung, tài liệu này có tên là manifest (imsmanifest.xml). Các file vật lý tham chiếu bởi file imsmanifest.xml Hình dưới sẽ minh hoạ cho các thành phần của một gói nội dung. hình: Các thành phần của gói nội dung. Manifest là file chứa các mô tả về các tài nguyên trong gói đồng thời nó cũng chứa thông tin về nội dung được tổ chức như thế nào. Manifest phải tuân theo các yêu cầu sau đây: Manifest file phải có tên là imsmanifest.xml imsmanifest.xml và các file điều khiển khác (DTD, XSD) phải đặt tại gốc của gói nội dung. Nếu mở rộng được bổ sung thêm bằng các file thì các file này cũng phải đặt tại gốc của gói. Tất cả các yêu cầu được đặt trong IMS Content Packaging XML Binding Specification. Các file vật lý là các file vật lý thực sự được tham chiếu bởi thành phần nội dung. File phục vụ cho mục đích trao đổi là file biểu diễn gói nội dung dưới dạng zip, rar, cab. File phục vụ trao đổi làm đơn giản hoá quá trình trao đổi giữa hai hệ thống. Thành phần của một manifest. File manifest biểu diễn các thông tin cần thiết để mô tả các nội dung của gói, nó gồm 4 thành phần chính như sau: Meta-data: dữ liệu mô tả tổng thể gói nội dung. Organizations: mô tả cấu trúc nội dung hoặc tổ chức các tài nguyên học tập tạo nên một đơn vị đứng độc lập hay các đơn vị giảng dạy. Resources: định nghĩa các tài nguyên học tập được gộp vào gói nội dung. (sub)Manifest: mô tả bất kỳ các đơn vị giảng dạy được phân cấp nhỏ hơn (có thể xem như các đơn vị độc lập). Các thành phần của nó được mô tả trong hình dưới đây: Thành phần của manifest. Như vậy LMS có thể xác định được các tài nguyên học và thứ tự duyệt của chúng trong gói nội dung thông qua file mainfest của gói. LMS đọc file manifest của gói và lưu các thông tin cần thiết vào một đối tượng SeqActivityTree. Khi có một yêu cầu duyệt khoá học của học viên thì LMS căn cứ vào thông tin trong đối SeqActivityTree để xác định tài nguyên học nào cần truyền tải đến học viên. Môi trường thực thi ( RTE). Với phạm vi giới hạn của đồ án là xây dựng hệ LMS, thì chúng ta cần xác định được các yêu cầu đối với hệ thống quản trị học trong việc quản lý môi trường thực thi. Thành phần RTE trong SCORM 2004 sẽ giúp cho ta hiểu quá trình phân phối nội dung, trao đổi thông tin chuẩn giữa nội dung và LMS, các thành phần dữ liệu chuẩn dùng để chứa các thông tin cần trao đổi. Tiếp theo chúng ta sẽ tìm hiểu kỹ hơn thành phần này của SCORM 2004. Giới thiệu. Thành phần RTE của SCORM 2004 mô tả các yêu cầu đối với LMS trong việc quản lý môi trường thực thi. Nội dung của nó gồm các phần chính sau: Run-Time Environment Management: Tìm kiếm và phân phối các đối tượng nội dung – SCO và asset, quản lý trao đổi thông tin với SCO, quản lý mô hình dữ liệu môi trường thực thi. Application Programming Interface(API): các yêu cầu về LMS API, các yêu cầu trao đổi thông tin SCORM, các điều kiện sẽ phát sinh lỗi trong trao đổi thông tin. RTE Environment Data Model: Quản lý mô hình dữ liệu và các yêu cầu hành vi, yêu cầu về kiểu dữ liệu. Trong phần tới, chúng ta sẽ trình bày các vấn đề sau: Phần 1 và phần 2: bao gồm các khái niệm cơ bản dùng trong RTE. Phần 3: API là phần đầu tiên cung cấp các chi tiết kĩ thuật về về RTE. Phần này cung cấp các phương thức SCORM API hoặc các thông báo lỗi đưa cho người phát triển nội dung, và ngoài ra cũng cung cấp các ví dụ mẫu. Phần 4: SCORM RTE Data Model mô tả các thành phần của mô hình dữ liệu SCORM chi tiết, chỉ ra các yêu cầu đối với LMS và SCO đối với một thành phần cho trước. Điểm qua về RTE. Cuốn sách này định nghĩa SCORM RTE Model mà chi tiết là tìm và phân phối các đối tượng nội dung, thiết lập trao đổi thông tin giữa LMS và SCO, và quản lý thông tin theo dõi có thể trao đổi giữa LMS và SCO. Trong ngữ cảnh của SCORM, các đối tượng nội dung sẽ là một trong hai trường hợp sau: Sharable Content Objects (SCOs) trao đổi thông tin trong lúc chạy, hoặc Assets không trao đổi thông tin lúc chạy. Cuốn sách mô tả cơ chế chung để tìm kiếm và hiển thị đối tượng nội dung, một cơ chế trao đổi thông tin chung giữa đối tượng nội dung và LMS, và mô hình dữ liệu chung để theo dõi tương tác của học viên với các đối tượng nội dung. Phải đặt ra những thứ chung như vậy nhằm giải quyết các yêu cầu cao về e-Learning của ADL. Một số vấn đề chính trong RTE được tóm tắt trong hình sau: Quá trình Launch xác định một cách chung để LMS bắt đầu các đối tượng nội dung dựa trên Web. Từ đối tượng nội dung được dùng theo nghĩa rộng để mô tả một phần thông tin có thể đưa đến cho một học viên. Trong SCORM có hai loại đối tượng là SCO và Asset. Quá trình launch xác định các thủ tục và trách nhiệm trong việc thiết lập giao tiếp trao đổi thông tin giữa đối tượng nội dung đã được khởi tạo và LMS. Quá trình liên lạc được chuẩn hóa thông qua API. API là cơ chế trao đổi thông tin chung để thông báo LMS các trạng thái trao đổi thông tin giữa một đối tượng nội dung và LMS (như khởi tạo, kết thúc, và các điều kiện phát sinh lỗi) và được sử dụng để lấy hay lưu trữ dữ liệu (điểm, các hạn chế thời gian…) giữa SCO và LMS. Data Model là một tập chuẩn các thành phần mô hình dữ liệu để định nghĩa thông tin được theo dõi bởi một SCO, như là trạng thái hoàn thành của SCO hoặc điểm của một bài kiểm tra. Theo nghĩa đơn giản nhất nó là một tập các thành phần mô hình dữ liệu mà cả LMS và SCO đều biết. LMS phải chịu trách nhiệm duy trì trạng thái của các thành phần mô hình dữ liệu của SCO thông qua các phiên học tập của học viên, và SCO phải sử dụng các thành phần mô hình dữ liệu được sử dụng lại trong nhiều hệ thống khác nhau. Quản lý môi trường thực thi. Khi tương tác với các đối tượng nội dung (learning experience), LMS sẽ đánh giá kết quả học tập của học viên và các yêu cầu duyệt. Khi LMS xác định một activity để phân phối cho học viên, activity sẽ có đối tượng nội dung gắn liền với nó. LMS sẽ hiển thị nội dung của content object và đưa nó tới cho học viên. Một số định nghĩa quan trọng. Learner Attempt: Một nỗ lực của học viên nhằm thỏa mãn các yêu cầu của một learning activity sử dụng content object. Một attempt có thể trải rộng trong nhiều session và có thể bị trì hoãn giữa các session của học viên. Learner Session: Một khoảng không bị gián đoạn trong lúc học viên truy cập content object. Communication Session: Một kết nối tích cực giữa content object và API. Login Session: Một khoảng thời gian bắt đầu từ lúc học viên bắt đầu một session (logged on) cho đến lúc học viên chấm dứt session (logged out). Trên hình vẽ mô tả cho ta các khái niệm ở trên quan hệ với nhau ra sao. Login Session là có phạm vi lớn nhất. Trong một Login Session có nhiều attempt, và trong một attempt có thể có nhiều learner session. Trong mỗi learner session sẽ có Communication Session. Đảm bảo tính thống nhất của Run-Time Data qua các Attempts và Activities. Trong một số trường hợp cần thiết để một learning activity có một và chỉ một run-time data, trải ra trong khắp các attempt của một học viên trên SCO gắn liền với activity. Yêu cầu này sẽ đặt ra bằng cách khai báo trong tài nguyên SCO sự cần thiết phải duy trì trạng thái của nó (run-time data) giữa các attempt. Chúng ta thông qua hai ví dụ để làm rõ vấn đề này. Trên hình vẽ hai activity là A12, A51 tham chiếu cùng đến một tài nguyên SCO. Bởi vì tài nguyên đã định nghĩa là Persist State là True, LMS phải chịu trách nhiệm duy trì run-time data model giữa các attempt trên. Hai activities A12, A51 tham chiếu đến cùng tài nguyên SCO. Tuy nhiên tài nguyên SCO có Persist State là false, thì LMS sẽ phải tạo một run-time data mới hoàn toàn cho các learner attempt trên SCO trong mỗi activity. Ví dụ, nếu trong một attempt trên Activity A12, run-time data sẽ được đặt bởi SCO, thì dữ liệu đó sẽ không được duy trì trong các attempt và các activities. Điều này có nghĩa là trong một attempt của học viên trên SCO tác động lên activity A51, dữ liệu đặt bởi activity A12 không được dùng nữa. Giao diện lập trình ứng dụng API. Phần này mô tả API của nội dung dùng để giao tiếp với dịch vụ thực thi (RTS). RTS được định nghĩa là một phần mềm dùng để điều khiển thực thi và phân phối nội dung học tập và có thể cung cấp các dịch vụ như định vị tài nguyên, lập kế hoạch, điều khiển đầu vào và ra và quản lý dữ liệu. Theo quan điểm của SCORM, hai từ RTS và LMS là tương đương với nhau. API cho phép trao đổi dữ liệu giữa nội dung và RTE cung cấp bởi LMS thông qua các dịch vụ API sử dụng ECMAScript. Một số khái niệm quan trọng: một vài khái niệm được dùng xuyên suốt trong SCORM như API, API Implementation và API Instance. Hãy xem hình vẽ dưới đây: Hình vẽ chỉ ra mối quan hệ giữa các khái niệm API, API Implementation, và API Instance. API: Theo nghĩa đơn giản nhất API là một tập các hàm được định nghĩa trước mà SCO có thể gọi. API Implementation: Là một phần mềm có chức năng dùng để thực thi và cung cấp giao diện hàm chuẩn của API. Tất nhiên API Implementation hoạt động như thế nào bên trong không quan trọng đối với người phát triển SCO, miễn là API Implementation cung cấp một loạt các public interface chuẩn. API Instance: Là một thể hiện của API Implementation trong một ngữ cảnh cụ thể. SCO sẽ có trách nhiệm khởi tạo phiên liên lạc với LMS. Hiện tại chưa có cơ chế nào được đặt ra để cho phép LMS khởi tạo các hàm thực thi bởi một SCO. Các phương thức cung cấp bởi API Implementation được chia làm 3 mục. Bảng dưới đây sẽ tóm tắt các mục đó. Phương thức Mô tả Các phương thức phiên Các phương thức phiên được dùng để đánh dấu sự bắt đầu và kết thúc của phiên trao đổi thông tin giữa SCO và LMS thông qua API Instance Các phương thức truyền dữ liệu Các phương thức này dùng để trao đổi các giá trị mô hình dữ liệu giữa SCO và LMS thông qua API Instance Các phương thức hỗ trợ Các phương thức này được dùng như các trao đổi thông tin phụ giữa SCO và LMS thông qua API Instance (chẳng hạn như lỗi phát sinh). Cú pháp và các phương thức của API: Các yêu cầu chung phải tuân theo khi thực thi API là : Tên các phương thức có phân biệt hoa thường rõ ràng và được chỉ ra ở các phần sau này. Các tham số của phương thức cũng phân biệt hoa thường rõ ràng. Các hàm dữ liệu đưa vào trong các tham số được biểu diễn như chuỗi kí tự. Chúng gồm 3 kiểu là các phương thức phiên (Initialize, Terminate), các phương thức trao đổi dữ liệu (GetValue, SetValue) và các phương thức hỗ trợ (GetErrorString, GetErrorCode, GetDiagnostic). Mô hình trạng thái phiên trao đổi thông tin. Các trạng thái trong phiên trao đổi thông tin là: - Chưa khởi tạo (Not Initialized) - Đang chạy (Running) - Kết thúc (Terminated) Trên hình vẽ cho ta thấy các trạng thái của phiên trao đổi thông tin: Not Initialized, Running và Terminated. Nó cũng cho chúng ta thấy trách nhiệm của SCO là tìm API Instance và gọi phương thức Initialize(). Các mã lỗi khi thực thi API. Tất cả các mã lỗi được xem như là các số nguyên biểu diễn như các chuỗi kí tự. Chuẩn IEEE yêu cầu tất cả các mã lỗi trong khoảng 0 đến 65536. Một khoảng định nghĩa trước cho các lỗi có thể phát sinh là từ 0 dến 999. Các mã lỗi bổ sung trong khoảng 1000 đến 65535. Mọi hàm API, trừ các phương thức hỗ trợ : GetLastError(), GetErrorString(), và GetDiagnostic(), đặt mã lỗi hiện thời cho API Instance, tức là mỗi lần gọi các hàm đó đều có một mã lỗi tương ứng đi kèm (Có thể có lỗi và có thể không có lỗi). Dưới đây là bảng tóm tắt các mã lỗi quy định bởi IEEE. Mục mã lỗi Miền giá trị của mã lỗi Không có lỗi 0 Lỗi chung 100-199 Lỗi cú pháp 200-299 Lỗi RTS 300-399 Lỗi mô hình dữ liệu 400-499 Các lỗi tự định nghĩa 1000-65535 Bảng mã lỗi khi thực thi API. Trách nhiệm của LMS. SCORM yêu cầu LMS cung cấp một API Instance như định nghĩa trong chuẩn IEEE và SCORM. API sẽ dấu SCO những thực thi bên trong cụ thể. Dưới đây chúng ta sẽ đi vào những yêu cầu cụ thể hơn. SCORM yêu cầu LMS cung cấp một API Instance thực thi chức năng của API mô tả trước đó. Để SCO có thể sử dụng tốt API Instance đặt ra bởi LMS, thì LMS phải có các yêu cầu nhất định về API Instance. Để cung cấp phương tiện để định vị API Instance, API Instance của LMS sẽ được cung cấp qua DOM như một đối tượng tên API là API_1484_11. LMS phải cung cấp khả năng cho SCO để truy cập API Instance thông qua ECMAScript. Để SCO tìm API Instance cung cấp bởi LMS, LMS phải chịu trách nhiệm phân phối SCO trong một kiến trúc phân cấp DOM cụ thể. LMS sẽ phân phối và hiển thị SCO trong một cửa sổ mà là cửa sổ con hoặc là frame con của cửa sổ LMS chứa API Instance. Trên hình vẽ là một số thí dụ về nơi đặt API Instance và nơi sẽ hiển thị nội dung của SCO. Tương lai thì LMS có thể có các phương pháp khác để SCO truy cập API Instance (như Web Service). Tuy nhiên vào thời điểm này, SCORM chỉ hỗ trợ các phương thức mô tả ở trên, DOM và ECMAScript là các kĩ thuật đáng tin cậy được dùng trong nhiều năm và rất dễ dùng. Trách nhiệm của SCO. SCO sẽ phải có những trách nhiệm nhất định khi trao đổi thông tin với API. SCO phải có khả năng tìm API Instance. Đây là lí do chính tại sao có những hạn chế trong việc API Instance được định vị ở đâu trong DOM hierarchy, và có một tên duy nhất đặt cho API Instance. Nếu API Instance đặt ở một nơi bất kỳ trong DOM hierarchy thì khó cho SCO trong việc tìm API Instance. Tìm API Instance. Bởi vì các đối tượng nội dung trong môi trường SCORM, được hiển thị bởi các Web Browser, Web Browser cung cấp DOM để đặt một API Instance. DOM có thể xem như một cấu trúc được định nghĩa hoặc một tổ chức các đối tượng trong một trang. Để SCO có thể tìm được API Instance trong nhiều LMS khác nhau, IEEE đã đặt các hạn chế về nơi đặt API Instance. Vấn đề quan trọng là SCO sẽ phải tìm API Instance trong các nơi sau : Chuỗi các cửa sổ mẹ của của sổ hiện tại, nếu tồn tại, cho đến khi cửa sổ đỉnh được tìm thấy. Cửa sổ mở nếu có. Chuỗi các cửamẹ của sổ mở, nếu tồn tại, cho đến khi cửa sổ mẹ cấp cao nhất được với tới. Hình vẽ trên chú giải việc tìm API của SCO. Đầu tiên đoạn mã tìm API Instance trong chuỗi các cửa sổ mẹ của cửa sổ chứa SCO. Nếu không có thì chuyển sang tìm chuỗi các cửa sổ mẹ của cửa sổ đang mở. Nếu tìm thấy thì trả về API Instance, còn nếu không tìm thấy thì trả về null. Mô hình dữ liệu trong môi trường thực thi của SCORM. Tổng quan về Data Model Mục đích của việc đặt ra data model là đảm bảo một tập thông tin được định nghĩa trước của SCO có thể được theo dõi bởi các môi trường khác nhau. Nếu ví dụ là cần thiết để xác định điểm của học viên được theo dõi là một yêu cầu chung, thì cần thiết để xác định một cách chung để thông báo điểm cho các môi trường LMS. Tthành phần data model dùng như là các tham số đầu vào trong các phương thức API. SCORM RTE Data Model dựa trên chuẩn P1484.11.1. đây là một chuẩn gồm một tập các thành phần mô hình dữ liệu có thể trao đổi thông tin giữa content object (SCO theo ngữ cảnh của SCORM) với LMS. Nó bao gồm một tập dữ liệu, nhưng không hạn chế, thông tin về học viên, các tương tác học viên có với SCO, thông tin mục tiêu, trạng thái thành công, và trạng thái hoàn thành. Các thông tin này sẽ rất quan trọng cho các mục đích khác nhau. Các dữ liệu sẽ được dùng trong đo mức độ tiến bộ của học viên, giúp đỡ trong việc đưa ra các quyết định xác định thứ tự dựa trên tương tác tổng thể với SCO. Do P1484.11.1 chỉ định nghĩa các thành phần mô hình dữ liệu và các kiểu dữ liệu của nó, SCORM cần áp dụng nhiều hơn các yêu cầu trong việc dùng, xác định mối quan hệ với API Instance. Các khái niệm cơ bản trong RTE Data Model. Thành phần trong Data Model: Để xác định mô hình, tất cả các tên của các thành phần data model mô tả trong SCORM RTE Data Model đều bắt đầu bằng “cmi”. Nó sẽ báo cho LMS rằng các thành phần dữ liệu này là thuộc IEEE P1484.11.1 Data Model for Content Object Communication draft standard. Tất cả các thành phần mô tả bởi SCORM được yêu cầu thực thi và các hành vi của nó phải được hỗ trợ bởi một LMS. Tất cả các thành phần dữ liệu đều là tùy chọn đối với SCO. SCO chỉ phải sử dụng các hàm Initialize(“”) và Terminate(“”); nó không nhất thiết phải gọi các hàm SetValue() và GetValue(). Tuy nhiên, nếu SCO muốn được theo dõi, chúng phải tuân theo mô hình dữ liệu chung để sử dụng lại được qua nhiều môi trường LMS. Tên các thành phần được gắn liền với các chuỗi kí tự ECMAScript sử dụng kí hiệu (.). Trong phương thức SetValue() gọi, tất cả các giá trị sử dụng để đặt thành phần mô hình dữ liệu được gắn với các chuỗi kí tự ECMAScript. Chuẩn ECMAScript hỗ trợ và tuân theo Unicode Standard. Đây là một điểm mà SCO và LMS phải lưu ý đến khi thực thi RTE Data Model. Ảnh hưởng của Data Model đến xác định thứ tự: SCORM Sequencing mô tả một chuỗi các đối tượng nội dung được xác định để phân phối dựa trên thông tin xác định thứ tự được định nghĩa, các hành vi xác định thứ tự và các kết quả tương tác của học viên với các đối tượng nội dung đã được phân phối. Asset có ảnh hưởng hạn chế hơn lên xác định thứ tự. LMS chỉ theo dõi sự kiện asset được phân phối. Sau khi asset đã hiển thị cho học viên rồi thì LMS coi như asset đã hoàn thành. SCO có thể có ảnh hưởng tới xác định thứ tự bằng cách thông báo các kết quả tương tác của học viên trong một phiên làm việc của học viên với SCO; tất nhiên sẽ thông qua SCORM RTE Data Model. Một LMS được yêu cầu sử dụng thông tin thông báo bởi SCO, qua RTE Data Model, để xác định ảnh hưởng lên việc xác định các thứ tự của các activities. SCORM không bắt một phương thức cụ thể hoặc về định thời như thế nào và khi nào SCO run-time data được dùng cho việc xác định thứ tự. SCORM chỉ yêu cầu là các thông tin gần đây nhất được sử dụng khi một đánh giá xác định thứ tự được tiến hành. Ví dụ, nếu SCO thông báo trạng thái hoàn thành của SCO thông qua cmi.completion_status, activity xác định xác định cùng với SCO sẽ được xem là hoàn thành. SCORM RTE Data Model. Các thành phần mô hình dữ liệu có thể được sử dụng để theo dõi trạng thái, điểm, tương tác, các mục tiêu…Một vài các thành phần mô hình dữ liệu ảnh hưởng lẫn nhau hoặc được dùng kết hợp với các thành phần khác. Một vài thành phần nếu sử dụng sẽ ảnh hưởng đến thứ tự của các SCO được dùng trong cùng một ngữ cảnh như bài học, khoá học. Dưới đây là bảng liệt kê các thành phần mô hình dữ liệu SCORM: Thành phần mô hình dữ liệu Mô tả Comments From Learner Chứa các chú thích từ phía học viên Comments From LMS Chứa các lời chú thích và ghi chú đự định đưa cho học viên Completion Status Chỉ ra học viên đã hoàn thành SCO hay chưa Completion Threshold Một giá trị mà đánh giá quá trình mà học viên cố gắng hoàn thành SCO có thể được so sánh để đánh giá xem SCO đã được xem là hoàn thành hay chưa. Credit Chỉ ra xem học viên có được công nhận thành công dựa trên kết quả tương tác với SCO. Entry Chứa thông tin kiểm tra tính đúng đắn của việc học viên đã truy cập vào SCO trước đó chưa Exit Chỉ ra như thế nào và tại sao học viên bỏ SCO Interactions Xác đinh thông tin liên quan với tương tác của học viên với SCO để đánh giá và đo lường Launch Data Cung cấp dữ liệu cụ thể cho SCO mà SCO có thể sử dụng để khởi tạo Learner ID Một định danh của học viên mà tương tác với SCO Learner Name Biểu diễn tên của học viên Learner Preference Xác định các sở thích của học viên sử dụng SCO Location Biểu diễn nơi định vị của một SCO Maximum Time Allowed Khoảng thời gian tích lũy học viên được phép để sử dụng SCO trong một attempt Mode Xác định kiểu mà SCO có thể biểu diễn tới học viên Objectives Xác định các mục tiêu học tập hoặc khả năng liên quan đến SCO Progress Measure Đo sự tiến bộ của học viên trong khi cố gắng hoàn thành SCO Scaled Passing Score Điểm đỗ đã chỉnh tỉ lệ của một SCO Score Điểm của học viên khi tương tác với SCO Session Time Khoảng thời gian mà học viên đã dùng trong phiên học tập hiện tại của học viên khi tương tác với SCO Success Status Chỉ ra học viên đã nắm được nội dung do SCO đặt ra hay chưa. Suspend Data Cung cấp thông tin có thể được tạo ra bởi SCO như là một kết quả của học viên truy cập hoặc tương tác với SCO Time Limit Action Chỉ ra cái gì SCO nên làm khi thời gian cho phép bị vượt quá Total Time Tổng của thời gian phiên học tập của học viên được tích lũy trong attempt hiện tại. Yêu cầu đối với LMS khi tuân theo chuẩn SCORM. Việc LMS tuân theo chuẩn SCORM 2004, được quy định trong từng cuốn sách, phân chia thành các kiểu tương thích khác nhau. Tương thích kiểu 1: LMS RTE 1.3 – LMS tuân theo các yêu cầu được định nghĩa trong SCORM RTE 1.3. Tương thích kiểu 2: LMS CAM 1.3 – LMS tuân theo các yêu cầu trong SCORM CAM 1.3. Tuơng thích kiểu 3: LMS SN 1.3 – LMS tuân theo các yêu cầu trong S&N 1.3. Để thử được các kiểu tương thích trên, LMS sẽ sử dụng một tập các gói các nội dung tuân theo SCORM 2004 được nhập vào LM