Powered by SmartDoc

5、Cluster Navigation System (分析編2)

システムコンテキスト分析

システムコンテキストとは、システムとアクタの間の境界、すなわちアクタからシステムまでの道のりのことである。この道のりとは、アクタもしくはシステムがお互いに対して起こすなんらかのアクションであると言い換えることができる。アクタとシステムは、お互いのアクションの相互作用によってある目的を達成する。

CNのシステムコンテキスト分析過程では、要求仕様を踏まえ、アクタとシステムの間で交わされる(ことを期待する)アクションを洗い出した。これはビジネスドメイン分析で明らかになった、現状の問題点をシステムに解決させることを目的とした、高レベルの曖昧なアクションである。そして洗い出されたこれらアクションを整理統合することにより、ユースケースを導出した。さらに導き出されたユースケースを詳細化し、そのユースケースを構成する正確なアクションを定義した。

システムコンテキスト分析の読み方

ここでは上に述べたユースケース及び、ユースケースを詳細化した結果得られた正確なアクション定義について記述している。このシステムには9つのユースケースが存在する。本文中では、はじめに全てのユースケースを順に説明し、その後それらに属するアクションの解説を行う。

システムコンテキスト分析中の定義

アクタの定義
例えば、「履修計画を立案する」ユースケース(以下UC)では、アクタは一つしか存在しない。「学生」アクタは、SFCの在学生をさし、以下のように表現される。
アクタの定義
ユースケースとアクションの定義
ここではシステムの「ユースケース」とシステムに対する学生の「アクション」を独自の観点から明確に切り分けていており、その定義は以下のようになっている。
ユースケースとアクションの定義
ユースケース

ユーザがこのシステムを何のために使うかを表したもの。

システムを通してユーザが"どのように変わるか"、"何を得られるか"がユースケースの考え方である。

アクション ユースケースを実現するために、ユーザがシステムに対して行う動作。

システムコンテキスト分析(ユースケース編)

CNシステムにおけるユースケースは以下の9つである。

UC1:履修計画を立案する

UC1:履修計画を立案する
アクタ
学生
目的
学生が、科目カリキュラムをもとに有用な履修計画を立てる。
事前条件
学生がシステムにログインしていること。
事後条件
学生にはSFCのカリキュラムを踏まえた履修計画が存在する。
説明

履修計画とは、学生一人一人が持つ学生生活を通しての科目履修を決める際の方向性のことである。本システムの目的の一つは、まず学生にこの「方向性」を持ってもらうことである。本システムでは、これを様々な方法で実現する。

  1. 学生に自分が所属するクラスターを決めてもらう(UC2)方法
  2. 興味ある科目と他の科目との関係を知り(UC3)、それを元に方向性を考える方法
  3. 他人の履修計画を参考にして(UC4)考える方法

本システムでは、これらを科目関係図として表示することで、より学生が理解しやすくする。さらに学生がこれに対して操作を行うことで、自分なりの履修計画が立てられるようにする。

includeするユースケース
内部アクション
イベントフロー

以下の図は、内部アクションの流れをアクティビティー図で記述したものである。左の図は、学生が"興味ある科目と履修した科目から科目関連図を作成"し、編集・保存するイベントフローを説明している。右に図は、学生が"クラスターから科目構造図を作成する"、"白紙から独自の科目関係図を作成する"、"保存されている科目関係図を閲覧する"を行ってから、その科目関係図を編集・保存するイベントフローを説明している。

UC1:履修計画を立案する

この大まかな手順をここで説明する。

  1. 学生は自分が考えやすい観点から科目関係図を生成する
  2. 生成された科目関係図に対して、学生は操作を行う(AC5)
  3. できあがった科目関係図を学生は保存する(AC6)
  4. 終了する

UC2:所属するクラスターを決める

UC2:所属するクラスターを決める
アクタ
学生
目的
学生が履修計画を立てるにあたって、自分の興味をもとに所属するクラスターを決める。
事前条件
学生がシステムにログインしていること。
事後条件
学生は自分の方向性と一致するクラスター、そして関係するクラスターを把握できている。
説明
クラスターは本来、学生が有用な科目履修をしてゆく上での目安となるものである。しかし現状ではどのクラスターが自分興味にあっているかが把握しづらいため、履修計画の目安となっていない。本システムでは、学生の履修してきた科目と興味ある科目をもとに、科目関係図を生成できる。これにより、学生はどのクラスターを自分が参考にすればいいのかが解る。
内部アクション
イベントフロー
以下の図では、内部アクションがどのような流れで実現され、最終的に学生が自分の所属するクラスターを決定できるかを表す。その大まかな説明を以下にする。
  1. 学生はまず自分の所属するクラスターを得るために、カリキュラム情報を取得する。これには、"クラスター制度の説明を得る"、"クラスター内の科目構成を把握する"、そして"科目情報を閲覧する"などが含まれる。
  2. その内容が把握した学生は、自分の所属するクラスターが把握することができる。しかし、それでも把握しづらい場合は、履修した科目、そして興味ある科目の登録を行う。
  3. 興味ある科目と履修した科目から科目関係図を作成する。
  4. 作成した科目関係図を閲覧し、それに対して操作を加えることで、自分の把握するクラスターが決定する。
UC2:所属するクラスターを決める

UC3:興味ある科目と他の科目との関係を知る

UC3:興味ある科目と他の科目との関係を知る
アクタ
学生
目的
学生が履修計画を立てるにあたって、自分が興味を持つ科目をもとに、その前提・推奨科目、そしてそれが前提・推奨となっている科目を知る。
事前条件
学生がシステムにログインしていること。
事後条件
学生は自分の方向性と一致するクラスター、そして関係するクラスターを把握できている。
説明

学生は科目シラバスを読むことで、その科目に興味を持つことがある。しかし、その科目を受けたらその先にどのような学習の方向性が広がるのかは見えてこない。本システムでは、学生は興味ある科目をもとに、関連する授業を図で閲覧できる。これには二つの方法がある。

  1. 一つの科目をもとにした科目関係図を作成する。
  2. 興味ある科目をもとに指定した複数の科目の科目関係図を作成する。

生成された関係図には、科目の前提・推奨科目、その科目を前提・推奨とした科目、そしてそれらの科目のクラスターが閲覧できる。

内部アクション
イベントフロー1
  1. 学生は、注目したい科目を決定し、それをもとにした関係図を作成できる。
  2. この方法で作成された図には、注目している科目の前提科目・推奨科目、そしてその科目が前提・推奨科目となっている科目が記される。さらに、それぞれの所属クラスターも記される。
  3. 科目関係図に対して操作を行い、それを保存できる。
  4. 終了する。
一つの科目をもとにした関係図を作成する
イベントフロー2
  1. 学生は、興味ある科目をあらかじめ登録しておく。
  2. 興味ある科目から、科目関係図を作成したい科目を複数選ぶ。
  3. 科目関係図を作成する。ここでは選択された複数の科目からみた関係図が生成される。生成される内容は、方法1と同じだが、注目されている科目が複数ある。
  4. 科目関係図に対して操作を行い、それを保存できる。
  5. 終了する。
興味ある科目一覧から複数の科目を選択し、それをもとに関係図を作成する

UC4:他人の履修計画を参考にする

UC4:他人の履修計画を参考にする
アクタ
学生
目的
学生が履修計画を立てるにあたって、他人の履修計画を参考にすることができる。
事前条件
学生がシステムにログインしていること。
事後条件
説明
学生が履修計画を立てる際、他人の履修計画を参考にした上で立てたいと考えることは多い。本システムでは、学生が他の人が作成した関係図を閲覧することで、他の人が大体どのようなことを考えて履修計画を行っているのかを把握できるようにする。
内部アクション
イベントフロー
  1. 参考にする科目関係図を選択する
    • 学部から選択
    • 人名一覧から選択
  2. 選択した他人の科目関係図を閲覧する
  3. 科目関係図に対して操作を行う。ここでは、他人の科目関係図が優れていて、それをもとに自分の関係図を作成したいと考えた場合、それができるようになっている。
  4. 科目関係図を自分用として保存する

UC5:カリキュラム情報を得る

UC5:カリキュラム情報を得る
アクタ
学生
目的
学生がカリキュラムの情報を得て履修の参考にするため
事前条件
利用者のログインが完了していること
事後条件
利用者のリクエストに応じたカリキュラム情報を得ることができること
説明
このユースケースは科目や教員の情報を探し、閲覧する機能全般である。ここには複数のシナリオが存在し、それらの相互関係に連続性がある場合とない場合があるが、イベントのフローとして表現することをここではしない。「カリキュラム情報を得る」というユースケースには、大きく分けて二つのシナリオが存在し、これをこの後分解することになる。
includeするユースケース
クラスター制度の説明を得る
内部アクション
簡易シナリオ
具体シナリオ
SFCにこの春入学したK君は、どのようにして履修計画を立てればいいのか、それについて役に立つといわれているクラスターとは何かについて疑問を持っていました、そこでCNにアクセスして、まずクラスター制度についての説明を読みました。
備考
上記のシナリオ1は前提シナリオとしての位置付けが考えられる。シナリオ2は「履修計画を行う」、「科目選択を行う」のユースケースを実現する為の手段でもあるが、ここでは興味のある科目等を発見するという、それらのユースケースに到るまでの前ステップとしての役割にのみ着目することにする。

UC6:クラスター制度の説明を得る

アクタ
学生
目的
学生が、的確な履修計画を行う為に、クラスター制度について正しい知識を得ること
事前条件
利用者のログインが完了していること。
事後条件
クラスター制度説明ページが表示されていること。
親ユースケース
カリキュラム情報を得る(UC5)
説明
クラスター制度の説明は、本システムを利用するにあたって欠かせないことであり、本ユースケースではそれを実現する。内部アクションとしては閲覧のみなので省略する。
イベントフロー
  1. 利用者は、閲覧画面に移動する。
  2. 利用者はリンクを辿って戻るか、ブラウザの戻るボタンで以前のページに戻る。あるいはブラウザを終了する。
シナリオ
学生K君は、入学したてでクラスター制度の存在意味が分からず、どうやって履修計画を行えばよいのか判りませんでした。そこでクラスター制度閲覧ページにとび、情報を読んで、それを理解することができました。
備考
本ユースケースはこのシナリオに限らず、多用なユースケースから知識補強、確認などの目的で参照される。

UC7:科目選択を行う

UC7:科目選択を行う
アクタ
学生
目的
学生が自分の履修計画を実践するために、興味のある科目を実際に時間割表に配置してみることによりその学期の授業選択をシミュレーションする。その際に、自分の履修計画を参照したり、授業情報を閲覧したり、単位的制約情報を得る手段を提供する
事前条件
カリキュラム情報を取得している、履修計画が立案されている
事後条件
選択科目が決定している
内部アクション
シナリオ
Aさんは新学期を迎えるにあたって、自分の立案した履修計画を実際の科目選択で実践しようと考えていた。そこでAさんはCNの履修計画シミュレーションシステムを利用することで、今学期の科目選択を考えてみることにした。Aさんはまず予め登録しておいた興味のある授業を、システムの時間割表に配置してみることにした。すると時間割の上でいくつかの授業が重複したので、もう一度授業情報や関連図に立ち戻って、どの授業を選択するかを決定した。また時間割に空白が目立ったため、適当な科目でその空白を埋めた。その際にはシステムが表示してくれる、自分の単位的な制約情報も参考にした。最後に、こうして出来上がった時間割をAさんはシステムに登録した。あとからその登録科目に関する情報をえるためである。
備考
本ユースケース記述では、履修計画などシステム利用者が作成した情報を見る場合は「参照」という言葉を使い、システム既存の情報を見る場合は「閲覧」という言葉を使用する。

UC8:自分の教員情報を学生に与える

UC8:自分の教員情報を学生に与える
アクタ
学生
目的
学生が、興味を持った教員について深く知ることを可能にさせる為に、教員が自らの情報を更新すること
事前条件
教員のアカウントが管理者によって作成されていること
事後条件
学生が教員情報を閲覧することが可能になっていること(教員情報が存在している場合)
説明
学生が教員情報を閲覧するにあたっては、教員が己の情報を登録し、公開する必要がある。本ユースケースはそれを実現する。教員のアカウントは管理者によって作成され、ログイン名と初期パスワードは事前にメールで連絡される。教員情報とは教員のプロファイルのことである。
内部アクション
イベントフロー
  1. 管理者が教員のアカウントを生成する。
  2. 管理者が教員にアカウントの情報を与える。
  3. 教員が教員情報の更新を行う。

UC9:担当科目情報を学生に与える

アクタ
学生
目的
学生が科目情報を利用するために、担当者が科目情報を提供する
事前条件
担当者がユーザー登録(学生登録、教員登録)を済ませていること
事後条件
科目情報に変更が行われる
説明
学生が科目情報を利用するには、科目の情報が担当者によって事前に更新されている必要がある。ここでの科目「担当者」とは、教員とそれを補助するSA,TAであり、教員は教員登録によって、SAやTAは通常の学生としてユーザー登録されていなければならない。担当者は自分がどの科目を担当するのかを登録し、その科目の情報を変更する権限をもつ。
内部アクション
イベントフロー
  1. 担当者(教員、SATA)は科目に対し、担当者登録をそれぞれ行う。
  2. システム認証後、担当者は、科目情報を更新する。

システムコンテキスト分析(アクション編)

CNシステムにおけるアクションは以下のような構成になっている。

科目関係図を作成するアクション

ここでは学生が科目関係図を新しく作り始める際、どのような手段が提供されているかについて説明する。

科目関係図を作成する

AC1:興味ある科目と履修した科目から科目関係図を作成する

アクタ
学生
目的
学生が自分の履修計画を立てる際、自分が今まで履修していた科目と自分が興味を持つ科目の、関係やクラスター内の位置付けを把握するために行う。
事前条件
ログインしている。
事後条件
科目関係図が作成・表示されている。
内部アクション
イベントフロー
  1. 学生は、CNシステムで検索を行ったりリンクを辿ったりして、科目情報ページへたどり着く。
  2. ここで、現在閲覧している科目を登録するか考える。
    • 科目情報ページを見て、それがすでに履修した科目ならば、それを履修した科目として登録する。
    • 科目情報ページを見て、それに対して興味が湧いたらならば、それを興味ある科目として登録する。
  3. 履修した科目と興味がある科目が一通り登録できるまで行う。
  4. 学生は、関係図ページから"興味ある科目と履修した科目の科目関係図"のリンクをクリックする。
  5. 興味ある科目と履修した科目を元にした科目関係図が表示される。

AC2:クラスターから科目関係図を作成する

アクタ
学生
目的
学生が、クラスター内の授業の様子と、その関係を解りやすい形で知りたいときに使う。学生が、一つのクラスターを中心に履修計画を立てたい場合も活用できる。
事前条件
ログインしていること。
事後条件
選択したクラスターを元にした構造図が作成・表示されている。
イベントフロー
  1. 学生は、関係図ページで科目関係図を表示したいクラスターのリンクをクリックする。
  2. そのクラスターの科目関係図が表示される。

AC3:白紙から独自の科目関係図を作成する

アクタ
学生
目的
独自の履修計画を考えるため、白紙から科目関係図を作りなおす場合に使う。
事前条件
ログインしていること。
事後条件
白紙の科目関係図が作成・表示されている。
イベントフロー
  1. 学生は、関係図ページで"新しい科目関連図を作成する"をクリックする。
  2. 白紙の科目関係図が作成される。

AC9:一つの科目をもとにした関係図を作成する

アクタ
学生
目的
学生が、一つの科目の前提・推奨となる科目、そしてその先の科目を知りたい場合に使う。
事前条件
ログインしていること。
事後条件
注目された科目を元にした科目関係図が作成・表示される。
発動条件
科目ページで、この科目を元にした構造図を閲覧するというリンクをクリックする。

AC10:複数の興味ある科目をもとにした科目関係図を作成する

アクタ
学生
目的
学生が、複数の科目とそれらと関係のある科目を知りたい場合に使う。
事前条件
ログインしていて、興味ある科目がすでに複数登録されていること。
事後条件
注目された複数の科目を元にした科目関係図が作成・表示される。
イベントフロー
  1. 学生はマイページから、"複数の興味ある科目を元にした関係図を作成する"リンクをクリックする
  2. 画面には、その学生が登録した興味ある科目の一覧と科目一つ一つに対応するチェックボックスが存在する。
  3. 学生は、関係図を起こしたい科目をその中からクリックし、OKボタンを押す。
  4. 画面には、複数の興味ある科目を元にした科目関係図が表示されている。

科目関係図に対してのアクション

ここでは学生が科目関係図に対して行うことのできるな具体的な操作に関するアクションについて説明する。

科目関係図に対して操作を行う

AC5:科目関係図に対して操作を行う

アクタ
学生
目的
履修計画を考えるツールとして科目関係図を個人用に操作するため。
説明
学生は、ここで紹介する操作を通して履修計画を考える。以下に記述する4つの図で操作を説明するが、これらの図は"科目関係図に対する操作"をわかりやすく説明するために4つに区切ったものである。
科目アイコンに対する操作
矢印・線に対する操作
囲い線に対する操作
メモ書きに関する操作

AC4:保存されている科目関係図を閲覧する

アクタ
学生
目的
保存されている科目関係図を再度閲覧・あるいは操作したい場合に使う。
事前条件
ログインしていること、そしてすでに保存してある科目関係図が存在すること。
事後条件
保存されている科目関係図が再度科目関係図として表示されていること。
イベントフロー
  1. 学生は、マイページから"保存した科目関係図を閲覧する"リンクをクリックする。
  2. 画面には、すでに保存した科目関係図の一覧とそのメタデータが表示されている。
  3. 学生は、再度閲覧したい科目関係図を決定し、そのリンクをクリックする。
  4. 画面には、保存されている科目関係図が表示される。

AC6:作成した科目関係図を保存する

アクタ
学生
目的
学生が作成した科目関係図を、後、そのままの状態で閲覧できるように保存する。
事前条件
ログインして、科目関係図を表示したこと。
事後条件
作成した関係図を再度開けるようにしてある。
イベントフロー
  1. 学生は、保存したい科目関係図に対して、メニューから保存を選ぶ。
  2. 学生は、保存をする科目関係図に対して名前を記入する。
  3. 学生は、保存する科目関係図を他人に公開するかしないかを決定する。公開する場合、公開するメタデータ項目を選ぶ。
  4. 保存に成功し、科目関係図を作成画面にもどる。

AC13:選択した他人の科目関係図を閲覧する

アクタ
学生
目的
自分の履修計画の参考にするために、他人の科目関係図を閲覧する。
事前条件
ログインしていること。他人が科目関係図を公開していること。
事後条件
他人が公開した科目関係図が閲覧できる。
内部アクション
イベントフロー
  1. 学生は、関係図ページから"他人の科目関係図を閲覧する"リンクをクリックする。
  2. 科目関係図を探索する方法を選ぶ。
    • 学部から
    • 人名一覧から
  3. 閲覧する科目関係図を決定し、そのリンクをクリックする。
  4. 選択した他人の科目関係図が画面に表示される。

AC25: 科目関係図にメタデータを記入する

アクタ
学生
目的
学生が複数の科目関係図を管理できるように、そして他人が参考にする科目関係図を選ぶ際の基準となるメタデータを作るために、科目関係図にはメタデータを加えることができる。
項目
必須項目
科目関係図の名前、図の公開・非公開
必須でない項目
図に対するコメント

AC26:科目関係図を印刷する

アクタ
学生
目的
自分が作成した科目関係図を紙媒体で扱いたい場合、図を印刷できる。
説明
科目関係図を作成しながら履修計画を立てる際、コンピュータといったメディアでは扱いづらいことが上げられる。履修計画を見直すときも同じである。そのようなとき、本システムでは科目関係図に書いてある情報を解りやすく印刷できる。

科目登録のアクション

学生は、履修計画や授業選択を行う上で、興味ある科目や履修した科目を把握しておかなければいけない。実際は科目の数が多く、学生がそれらを把握することは困難である。さらに、ここでは学生の履修計画をシステム的にサポートするため、システムでもこれらの科目を把握しておく必要がある。そのために、本システムでは学生は科目の登録が行える。

科目を登録する

AC7:興味ある科目を登録する

アクタ
学生
目的
自分の興味ある科目を登録し、それを元に科目関係図を作れば、自分の方向性が見えやすくなる。さらに、興味ある科目を元に科目選択を行う。
事前条件
ログインしていること。
事後条件
興味ある科目が登録されていること。
イベントフロー
  1. 学生は、検索を使ったりリンクを辿ったりして科目ページへとたどり着く。
  2. 科目ページについたら、学生は科目ページの内容を読む。
  3. 読んだ内容から、その科目に興味を持ったら、「興味ある科目に登録する」ボタンを押す。
  4. マイページの「興味ある科目一覧」に選択された授業が登録されている。

AC8:履修した科目を登録する

アクタ
学生
目的
単位計算を行う際や、履修計画の方向性を立てる際に履修し、単位を獲得した科目を登録しておく必要性がある。
事前条件
ログインしていること。
事後条件
すでに履修し、単位を獲得した科目が登録されていること。
イベントフロー
  1. 学生は、以前履修を行って単位を獲得した科目の科目ページを探す。
  2. 科目ページで、"履修した科目に登録する"ボタンを押す。
  3. マイページの「履修した科目一覧」に選択された授業が登録されている。

参考にする科目関係図を選択するアクション

本システムでは他人の科目関係図を閲覧することができる。本章では、学生参考にする科目関係図にたどり着く方法と、その際に公開される検索メタデータを説明する。

参考にする科目関係図を選択する
他人に公開されるメタデータ
学生が、公開されている科目関係図を探す際、自分が参考にしたいものかどうかを探すための情報が必要である。ここで、公開されている科目関係図に付随するメタデータの種類を明らかにする。
作成者情報
作成者名、ログイン名、所属学部
日時情報
作成日時、最終編集日時
その他
科目関係図名、科目関係図に対するコメント

AC11:参考にする科目関係図を学部から選択する

アクタ
学生
目的
学生が自分の履修計画を考える際、参考にする他の学生の履修計画を選ぶ方法。
事前条件
学生がログインしている
事後条件
学生が、参考にしたい他人の履修計画を発見している
イベントフロー
  1. 科目関係図ページから、「他人の科目関係図を閲覧する」の項目にある「学部から」のリンクをクリックする。
  2. 画面には、参考にできる科目関係図の一覧と、それに関する情報の一覧が表示される。
  3. 学生は、閲覧したい科目関係図のリンクをクリックすることで、閲覧できる。

AC12:参考にする科目関係図を人名一覧から選択する

アクタ
学生
目的
学生が自分の履修計画を考える際、参考にする他の学生の履修計画を選ぶ方法。
事前条件
学生がログインしている
事後条件
学生が参考にしたい他人の履修計画を発見している
イベントフロー
  1. 科目関係図ページから、「他人の科目関係図を閲覧する」の項目にある「人名から」のリンクをクリックする。
  2. 画面には、参考にできる科目関係図の一覧と、それに関する情報の一覧が"あいうえお順"表示される。
  3. 学生は、閲覧したい科目関係図のリンクをクリックすることで、閲覧できる。

カリキュラム情報を閲覧するアクション

この章では、カリキュラム情報の閲覧に含まれるアクションを説明する。検索、探索と閲覧が主なアクションである。

AC13:得たい情報にたどり着く

アクタ
学生
目的
学生がカリキュラムについて興味のある事項を発見する。
事前条件
利用者のログインが完了していること。(そして得たい情報が何か、目的が存在していること)
事後条件
利用者のリクエストに応じ、探索や検索結果となるカテゴリや検索結果項目が表示されていること。
説明
このアクションでは、ユーザーの行為によって複数のシナリオが発生し、分岐するが、全て「検索」と「カテゴリを辿る」、の組み合わせである。「得たい情報にたどりつく」ということは、その行為そのものを意味するものであり、辿りつく為の手段を明確にする為のものであるので、手段の具体性や閲覧自体は含まれない。
イベントフロー
  1. 利用者は、検索か探索(カテゴリから辿る)を行う。
  2. 出てきた結果によって、閲覧か再検索、再探索を行う。
簡易シナリオ
  1. 検索→カテゴリから辿る→閲覧
  2. カテゴリから辿る(一回または繰り返し)→閲覧
  3. 検索(一回または繰り返し)→閲覧
AC13:得たい情報にたどり着く

AC14:情報を検索する

アクタ
学生
目的
学生が関心のある事柄を検索し、それに関する知識を得ること。
事前条件
利用者のログインが完了していること。検索に必要な項目が満たされていること。
事後条件
利用者のリクエストに応じ、検索結果となる検索結果項目が表示されていること。
親アクション
得たい情報にたどつく
説明
情報の検索には、その検索手段と手法が含まれる。手段はイベント内のシーケンスへ、手法は継承アクションとして表現される。
イベントフロー
  1. 利用者は、検索画面に移動する。
  2. 利用者は目的に応じて検索項目を入力し、送信ボタンをおす。
  3. システムは検索を行い、結果を返す。
  4. 利用者は検索結果を閲覧し、結果に応じてさらなる検索か、探索か閲覧かを選ぶ。
シナリオ
学生K君は、噂にきく政策過程論では具体的に何が学べるのかを知りたくなりました。そこでシステムにログインし、検索画面にとんだ後、検索ボックスにその科目名を入力し、送信ボタンを押しました。すると結果として1件、巨石教員の政策過程論が表示されました。K君はこれを選択し、閲覧することにしました。
AC14:情報を検索する

AC15:カテゴリからたどる

アクタ
学生
目的
学生が関心のある事柄を一覧から選択し、自分の得たい情報に近づいていくこと。
事前条件
利用者のログインが完了していること。カテゴリの一覧が表示されていること。
事後条件
利用者のリクエストに応じ、サブカテゴリが表示されていること。また、検索ができるようになっていること。
親アクション
得たい情報にたどつく
内部アクション
説明
(親)カテゴリの下に所属するカテゴリをサブカテゴリという。本ユースケースはサブカテゴリへと親カテゴリを行き来することを意味する。サブカテゴリの下には、サブカテゴリかアイテム(ここでは科目、教員などの情報実体)が属する。
イベントフロー
  1. 利用者は、カテゴリ一覧画面に移動する。
  2. 利用者は目的に応じてカテゴリを選ぶ。
  3. システムは要求されたカテゴリ内にある項目の一覧(サブカテゴリ一覧)を返す。
  4. 利用者はサブカテゴリ一覧をみて、さらにサブカテゴリを辿る。
  5. アイテムを閲覧するか、検索に切り換えるかを選ぶ。
シナリオ
学生K君は、PPクラスターに興味があり、この中にどのような科目があるのかを探索することにしました。K君はクラスターカテゴリ一覧ページに行き、PPクラスタのカテゴリを選び、科目一覧を表示しました。そしてその中の政策過程論をとりあえず閲覧することにしました。
AC15:カテゴリからたどる

AC16:形式化された情報を閲覧する

アクタ
学生
目的
学生が、関心のある事柄を得る為に、項目が形式化された情報を閲覧する。
事前条件
利用者のログインが完了していること。(多くの場合検索か探索(カテゴリを辿ること)が完了していること。
事後条件
利用者のリクエストに応じた情報が表示されていること。
親ユースケース
カリキュラム情報を得る
内部アクション
説明
システムにはカリキュラムについて様々な情報が登録されるが、本ユースケースはそれを一括し表現するものである。
イベントフロー
  1. 利用者は、閲覧画面に移動する。
  2. 利用者は、閲覧ページにある項目のリンクを押す。
  3. システムは要求された項目の閲覧ページをかえす。
  4. 利用者は閲覧ページをみて、場合によってさらなる閲覧を行うか、一つ前に戻るか、閲覧を終了する。
シナリオ
学生K君は、自分が興味を持った政策過程論の閲覧ページにたどりつき、これを閲覧しました。これがおもしろそうだったので、担当している教員のことも知りたくなり,教員ページにとんでこれも閲覧しました。が、教員の顔が気に入らなかったのでブラウザの×を押しました。
備考
フローもシナリオも蛇足にすぎない・・本当のアクションは閲覧のみである

担当者と教員のアクション

この章では担当者と教員が行うべきアクションを記述する。具体的には教員と科目にかかわる情報の更新が含まれる。

AC17:教員情報を更新する

アクタ
教員
目的
教員が、諸事情から教員情報を変更する。
事前条件
教員情報が新規作成されていること。教員のログインが完了していること。
事後条件
教員情報に変更が加えられ、学生がそれを閲覧できるようになっていること。
親アクション
自分の教員情報を学生に与える
内部アクション
説明
長期的にも短期的にも教員情報は更新されるべきものである。このアクションでは教員情報の変更を行う。ここではログイン後には教員用アカウント画面があると仮定する。
イベントフロー
  1. 教員はログインを行い、アカウント画面に移動する。
  2. アカウント画面からプロファイル変更画面にいく。
  3. プロファイル変更画面において、必須情報を入力し送信ボタンを押す。
  4. 確認画面がでてくるので、確認ボタンを押す。
  5. 変更完了画面がでてきて登録が完了する。
シナリオ
教職二年目のBさんは、自分のバイブル的辞書が見つかったので、これを履修支援システム登録にすることにしました。ログインを行い、情報変更画面でバイブルを入力して送信ボタンを押し、確認画面で確認ボタンを押すと、バイブルが無事登録されました。

AC18:担当者登録を行う

アクタ
担当者(TASA、教員)
目的
科目情報を変更する権限を得る。
事前条件
担当者がユーザー登録(学生登録、教員登録)を済ませていること。教員用のパスワードと、SATA共通用のパスワードが事前に担当者に知らされていること。
事後条件
担当者が、科目情報を更新することができるようになる。
内部アクション
説明
教員やTASAが、担当者として登録する場合、教員には教員用の、TASAには彼ら共通用にパスワードが管理者から送られてきているので、それを使って登録する。具体的には、ログイン名を入力し、入力されたパスワードと科目に用意されたパスワードが一致すれば、そのユーザーは担当者として登録される。一旦登録されれば、以降は通常のログインで、担当者としての利用も可能になる。
イベントフロー
  1. 担当者登録画面にいく。
  2. 担当者登録画面で、ログイン名、科目用パスワードを入力し、担当科目をプルダウンリストから選んで登録ボタンをおす。
  3. 担当者としての登録が完了する。
シナリオ
熱血SAの某Y.I.君は坂田先生の情報処理SAになったので、履修支援システムにおいて、担当者として科目情報を更新するために、担当者登録を行うことにしました。登録画面で、ログイン名、管理者からもらったパスワードを入力し、坂田先生のクラスを選んで登録ボタンを押しました。これでYI君は自分の履修計画ページから、担当科目情報更新画面へアクセスすることが可能になりました。

AC19:担当科目情報を更新する

アクタ
担当者(TASA、教員)
目的
科目情報を変更する権限を得る。
事前条件
担当者がユーザー登録(学生登録、教員登録)と担当者登録を済ませていること。
事後条件
科目情報が変更される。
説明
更新の対象となる科目の情報には、それぞれの分類項目や、SAの伝言板などがあるが、これらを担当者はフォーム入力で更新する。
イベントフロー
  1. 担当者のページにある、担当科目の一覧から、更新対象となる科目を選び、科目情報更新画面にいく。
  2. 科目情報更新画面で、更新される情報をフォーム入力し、更新ボタンをおす。
  3. 更新された科目情報の画面が表示される。
シナリオ
坂田先生の情報処理SAの某Y.I.君は、先生からの必殺の一言を載せるために、科目情報を変更することにしました。IY君の履修計画ページにある、担当科目から情報処理1BC(坂田)を選び、科目情報更新ページにいきました。そこで「先生からの一言」項目に「君達の市場価値は・・」を書き、更新ボタンをおしました。すると更新された科目のページが表示されました。

科目選択を行うためのアクション

ここでは科目選択と時間割の操作を、どのように行うかを説明する。時間割に関するアクションと、単位計算に関するアクションが含まれる。

AC20:時間割を作成する

AC20:時間割を作成する
アクタ
学生
目的
履修計画の実践のシミュレーションを行うために、実際に選択する科目を配置した仮想時間割表を作成する。
事前条件
なし
事後条件
時間割表が作成されている。
内部アクション
シナリオ
Aさんは時間割を作成するにあたって、まず興味のある科目を次々に時間割表に配置していった。同じ時間帯に選択したい科目が重複した場合は、一応両方の科目を配置した。配置してみた後で、自分の立てた履修計画や、単位的制約を十分考慮した。そして単位的制約や自分の履修計画との不適合などの理由で今回は履修を見送った方が良いと思われる科目は削除した。その後で、やはり選択したほうが良いと思われたものは、時間割に再配置した。最後に、後でまた時間割の見直し・修正が可能なように、時間割を保存した。そして学期が始まると、実際に履修申告した科目を時間割にも登録した。
備考
このアクションは以下の2つのグローバルなアクションに含有される。

AC21:興味ある科目を時間割に配置する

AC21:興味ある科目を時間割に配置する
アクタ
学生
目的
時間割を作成するにあたって、自分の履修計画や単位的制約と整合性のとれた科目が時間割に重複なく配置されているようにする。
事前条件
なし
事後条件
興味ある科目が重複なく、よく考慮されて時間割に配置されている。
内部アクション
具体アクション
シナリオ1
Aさんは科目を時間割に配置するにあたり、ある時間帯において選択したい科目が重複するという問題に直面した。Aさんはこの問題に対して、履修計画と授業情報を振り返り、どちらが自分にとって有益かを考慮することで解決した。
シナリオ2
Aさんは科目を時間割に配置するにあたり、1日の時間割に時間帯の空白がありすぎてしまうという問題に直面した。時間割からその時間帯に開講する科目を調べ、その中から最も適当であると思われる科目を選択することで解決した。
シナリオ3
Aさんは科目を時間割に配置するにあたり、単位的な制約により選択不可能または選択すると不利になる科目があるかもしれないという問題に直面した。この問題に対しては、Aさんが自分で考えるまでもなくシステムが自動的に通知してくれた。それによると、Aさんの選択した科目の中に1つの履修不可能な科目があり、履修すると単位的に不利になる科目が2つあるとのことだった。
備考
このアクションが「科目選択を行う」ユースケースの本質である

AC22:単位制約情報を閲覧する

AC22:単位制約情報を閲覧する
アクタ
学生
目的
時間割に興味のある科目の配置を行う際に、自分の単位の制約情報を反映させる。
事前条件
時間割が開いている。
事後条件
単位制約情報を得ている。
内部アクション
シナリオ
今期限りで卒業のAさんは、今期の時間割に科目を配置する際に、自分の単位的な制約を十分考慮に入れる必要があった。そこでAさんは時間割の傍らに表示されている、分野ごとの残り単位数、取得済みの単位数、時間割に登録した科目の単位合計を照らし合わせながら配置を進めた。

AC23:履修計画を参照する

AC23:履修計画を参照する
アクタ
学生
目的
時間割に興味のある科目の配置を行う際に、自分の履修計画を振り返り、それを配置に反映する。
事前条件
時間割が開いている。
事後条件
自分の履修計画を振り返ることができている。
内部アクション
シナリオ
Aさんは興味のある科目を時間割に配置していく過程で、自分の本来の履修計画を見失ってしまった。自分の興味に従って時間割に配置する科目を選んでいるうちに、選び出された科目が全くの無秩序なものとなってしまったからである。そこでAさんは、一度自分の立てた履修計画を振り返ってみようと思った。Aさんは時間割画面から、自分が過去に作成した履修予定科目の関連図を参照した。そしてそれに基づいて、無秩序な科目選択を修正していった。
備考
学生の履修計画のアウトプットとしてシステムに保存されるのは、(現段階では)履修予定科目の関連図だけである。よってこのアクションでは、その関連図を振り返ることだけが可能である。

AC24:科目情報を閲覧する

AC24:科目情報を閲覧する
アクタ
学生
目的
時間割に興味のある科目の配置を行う際に、授業情報を手軽に再確認できるようにする。
事前条件
時間割が開いている。
事後条件
科目情報を得ることができている。
内部アクション
シナリオ1
Aさんは時間割に科目の配置を行う過程で、同じ時間に取りたい科目が重複してしまった。そこでAさんはこの2つの科目の授業情報を照らし合わせてみることにした。Aさんはとりあえず2つとも時間割に配置し、その後でその両科目をダブルクリックした。すると別ウィンドウでそれぞれの科目情報が開いたので、それらをじっくり照らし合わせ、より自分にふさわしい科目を選択した。
シナリオ2
Aさんは時間割に科目の配置を行う過程で、金曜日の1限と5限に授業を配置したところ、その間に時間の空白ができすぎてしまった。そこでAさんはその時間帯で履修できる科目を探すべく、その時間帯に履修可能な科目一覧を閲覧した。するとそこにはAさんの興味と合致する科目がいくつか含まれており、Aさんはこれをもとに時間の空白に配置する科目を選択した。