本发明中的监视程序。关于主观测器的动作后述。
[0060]通过代码写入部26将所生成的执行程序30写入到在实际环境中动作的计算机具有的存储装置(ROM)。在实际环境中动作的计算机是指，例如搭载在汽车上的车载计算机(ECU)等。
[0061]图4是示出第一实施方式的软件开发步骤的流程图。软件开发者通过代码生成部23根据软件要件生成应用代码(Sll)，并且，通过测试脚本生成部22根据软件要件设计测试脚本(S12)。步骤Sll和步骤S12的顺序既可以首先进行某一个，也可以并行地进行。
[0062]然后，在观测器生成部24中，在根据测试脚本生成了观测器代码(S13)之后，在代码合成部25中，构筑应用代码和观测器代码这双方(S14)。由此，得到执行程序30。最终，由代码写入部26将所生成的执行程序30写入到对象的计算机(S15)，完成软件开发。
[0063]〈程序的监视方法〉
[0064]接下来，说明写入到计算机的程序的动作。在本实施方式中，计算机是指搭载在车辆上的车载终端。图5是执行执行程序30的车载终端100的系统结构图。
[0065]车载终端100具有运算处理装置101以及存储装置102。执行程序30储存于存储装置102，通过运算处理装置101被执行。另外，利用者能够通过输入装置103进行针对监视对象程序32的输入。输入装置103在本实施方式中是触摸面板，但也可以是键盘、指示设备。
[0066]另外，车载终端100具有用于与外部进行无线通信的通信装置104、以及用于记录信息的盘装置105。
[0067]通过具体的例子，说明观测器判定针对监视对象程序的输入操作是否沿着测试脚本的方法。图6是各观测器保持的测试脚本的例子。另外，图7是示出通过利用者的操作实施的监视程序的状态迀移的图。例如，能够在从主菜单迀移到子菜单I之后，按照操作A、操作B、操作C、操作D的顺序进行操作。与该一连串的操作相应的测试脚本是测试脚本I以及2。在各测试脚本中，这样记录有进行程序的测试时的操作的顺序，各观测器(31A、31B、31C...)逐个存储测试脚本。在本例子中，为了监视图6所示的全部测试脚本，使用6个观测器。
[0068]可知仅在利用者当前进行的输入操作与记录在某一个观测器所存储的测试脚本中的操作一致的情况下，该操作是在程序的测试阶段获得了动作确认的操作。相反地，在进行了与哪个测试脚本都不一致的操作的情况下，能够判定为是未进行过动作确认的状态、即未验证状态。
[0069]使用观测器的激活/非激活这样的语言，说明用于判断利用者当前进行的输入操作与哪个测试脚本一致的方法。“观测器处于激活状态”意味着，利用者进行的输入操作处于与该观测器具有的测试脚本一致的状况。另外，“观测器处于非激活状态”意味着，利用者进行的操作处于与该观测器具有的测试脚本不一致的状况。各观测器能够根据所取得的输入操作、和本观测器存储的测试脚本的比较结果，切换本观测器的状态(激活状态/非激活状态)。
[0070]举出具体的例子进行说明。测试脚本分别从成为起点的画面启动。在图6的例子中，主菜单画面是所有测试脚本的起点。即，在监视对象程序显示了主菜单的状态下，成为与所有测试脚本相应的状态，所有观测器成为激活状态。
[0071]首先，对监视对象程序输入利用者所进行的操作。在监视对象程序的代码中，与取得输入操作的函数一起还定义有接入点，每当利用者进行输入操作时，执行方面。在方面中，描述有取得输入操作而发送到观测器的处理，由此，所输入的操作被发送到所有观测器。
[0072]例如，如果进行了“菜单迀移操作1”，则该操作被发送到所有观测器。该操作是仅与测试脚本I?3相应的操作，所以仅与测试脚本I?3对应的观测器成为激活状态，其他观测器成为非激活状态。这样，随着操作的进展，激活状态的观测器减少。然后，如果再次返回到作为起点的主菜单，则所有观测器返回到激活状态。这样，通过利用者的操作，各观测器的激活状态和非激活状态随时被切换。
[0073]例如，从主菜单依次进行了以下的操作时的、处于激活状态的观测器的一览如以下所述。另外，此处为便于说明，将与例示了的测试脚本I?6对应的观测器分别称为观测器I?6。
[0074](I)初始状态(主菜单):观测器1、2、3、4、5、6
[0075](2)菜单迀移操作1:观测器1、2、3
[0076](3)操作 A:观测器 1、2、3
[0077](4)操作F:观测器3
[0078](5)操作G:观测器3
[0079](6)操作 Z:观测器 1、2、3、4、5、6
[0080]在本例子中，主菜单是各测试脚本的起点，所以通过进行操作Z，所有观测器返回到激活状态。
[0081]本实施方式的监视程序31能够根据观测器的激活状态，判定监视对象程序32是否为已验证的状态。在图8的流程图中，示出在车载终端100上动作的监视程序31进行的监视处理。如果在车载终端100上开始了执行程序30，则开始图8的流程图。
[0082]首先，在步骤S21中，每当利用者进行输入操作时，所有观测器取得该输入操作。接下来，在步骤S22以及S23中，各观测器比较在步骤S21中所取得的操作、和自己具有的测试脚本。其结果，在本观测器是激活的对象的情况下，切换为激活状态(S22)，在是非激活的对象的情况下，切换为非激活状态(S23)。成为非激活状态的观测器对主观测器31M通知非激活了的意思。
[0083]步骤S24是检测所有观测器是非激活状态的步骤。具体而言，主观测器31M对处于激活状态的观测器的数量进行计数。此处，在处于激活状态的观测器一个都没有的情况下，意味着正在进行测试脚本中没有的操作，所以迀移到步骤S25，主观测器31M发生用户出错这样的事件。用户出错是指，通知程序成为未验证状态的事件。例如，考虑在控制车辆的系统成为用户出错状态的情况下，使系统转移到作为驾驶中必要最低限的构成的安全模式。另外，也可以在处于认为比较安全的状况的情况下，仅进行针对驾驶者的通知。
[0084]如果发生了用户出错，则主观测器31M起动用于通知异常的外部程序，该外部程序通过LED、IXD等显示器(未图示)，对驾驶者通知发生了异常的意思。另外，在盘装置105中，将关联的信息记录为日志。记录的信息是程序的存储器转储、利用者进行了的操作的日志等。另外，这些日志信息也可以通过通信装置104发送到管理中心200。另外，也可以对监视对象程序通知发生了异常的意思。
[0085]另外，在处于激活状态的观测器有一个以上的情况下，处理迀移到步骤S21，再次等待输入操作。
[0086]根据本实施方式，通过在计算机上执行的观测器监视针对监视对象程序的输入，能够检测由利用者进行了未被测试的样式的输入操作。由此，能够在系统成为危急的状态之前进行通知，能够提高系统的安全性。
[0087]另外，在第一实施方式中，在观测器全部成为非激活状态的情况下，主观测器发生了用户出错，但也可以设置检查观测器的激活状态的其他程序，在所有观测器成为非激活状态的情况下，该程序发生用户出错。
[0088]另外，在第一实施方式中，在发生了用户出错的情况下，在进行了必要的处理之后结束动作，但在发生了用户出错之后观测器再次激活化了的情况下，也可以在进行了恢复处理之后继续监视。恢复处理既可以是对外部通知再次成为已验证的状态的处理，也可以是使系统的模式从安全模式复原为通常模式的处理等。
[0089]另外，在本实施方式中，将主菜单作为各测试脚本的起点，在画面迀移到主菜单时，进行全部观测器的激活，但能够根据测试脚本，使观测器激活的定时为任意的定时。例如，既可以有在迀移到子菜单时被激活的观测器，也可以有在满足了任意的条件的情况下被激活的观测器。
[0090]另外，作为对象的语言也可以是Java以外的语言。只要能够使用面向方面的框架，则也可以是例如C语言、C++、PHP等，只要能够通过某种方法对观测器通知针对监视对象程序的输入操作，则也可以不使用面向方面