lecture04 System Specification • Specify system

Document Sample
lecture04 System Specification • Specify system Powered By Docstoc
					         System Specification
•   Specify system goals
•   Develop scenarios
•   Define functionalities
•   Describe interface between the agent
    system and the environment
           Goal Specification
• Identify Initial Goals
  Start with system description, e.g., from:
     • We wish to develop a student enrollment system
       that allows students to enrol in subjects, add and
       delete subjects in accordance to rules and view
       their enrolment. Enrolment rules should be editable
       by authorized staff
     • We would like to develop a fully online system for
       world wide sale of books. This system will offer a
       broad range of books to customers, and a
       personalized, friendly user interface. The system
       must facilitate fast and reliable service at all
       stages, from locating a desired book, to deliver of
       the purchase. The store should have competitive
            Goal Specification
• Goal Refinement
     • By asking “how”, e.g., for goal
         – fully online system:
         Sub-goals: find books online, pay online and order online
         – purchase books:
         Sub-goals: find books, place order, make payment, and arrange

     • Analyze all sub-goals to:
         – eliminate duplicates,
             » pay online and make payment
         – coalesce similar ones
             » deliver internationally, arrange courier delivery, and
               arrange delivery into arrange delivery
         – elaborate goals
             » Add to Profile Monitor the sub-goals register and update
               the customer profile
     Goal Refinement (cont.)
   – rearrange them
       » Goals with no sub-goals left will disappear, e.g.,
         World-wide Sale of Books
       » Replace a sub-goal with a more detailed one, e.g.,
         have books available in stock with reorder stock, with
         sub-goals to log outgoing and arriving books
       » Some original goals may expand, e.g., Delivery of
         Books expands to Arranging Delivery and Delivery
• Goal Overview Diagram (e.g., page 140)
• Def: Chunk of behavior, which includes a
  grouping of related goals, as well as
  percepts, actions, and data relevant to the
  – Use functionality descriptors (e.g., page 141)
  – Draw functionality diagram (e.g., page 42)
• Scenario Development
     Complementary to goals, in that they show the
      sequence of steps that take place within the
      Scenario Development
– Core scenario steps: achieving goal, performing
  action, receiving a percept, referring to another
  scenario, waiting for something to happen
– May lead to new goals/subgoals/percepts/actions
  Query Late Books Scenario leads to new goal Update
   delivery problem. We had Log delivery problem, but
   discovered the need to update the information once the
   information from the tracking request had been
   received. Also, two percepts (original user query from
   the web interface and the response to the tracking
   initiated) and an action (request for tracking of the
   delivery) are recognized.
– Fully developed steps for Query Late Books
  Scenario (see page 45)
     Capturing Alternative Scenarios
• With each scenario (for a complete list see page
  47) include a description of possible alternatives
  (e.g., other than normal, and exceptions) - see
  page 46
• Use a collection of scenarios that all relate to a
  single underlying process (e.g., order book:
  normal, and other where book may not be
• Issues:
  – When do we stop defining scenarios
  – What is the right level of detail for describing
    scenarios and alternative/exceptional scenarios
         Interface Description
• To answer: how is the agent system going to
  interact with the environment? Specifically,
  – What input about the environment will be
    available to the agent system while it is running
    (i.e., percepts)
  – What will the agent system do to interact with and
    affect the environment (i.e., actions)
• Often require some processing in order to
  extract the information that is of value to
• Important to understand nature and use of
  precepts in design of agent
• Investigate and experiment with potential
  sources of percepts. Account for noise
• For list of percepts for E-Bookstore (see
  page 49)
• If applicable study the physical effectors
  resulting from percepts, e.g.,:
  – A system may be designed to have an action
    move, with parameters giving distance and
    speed. This action will require complex
    feedback loops within the effector system to
    enable this action to be carried out.
  – If applicable, ensure correctness of interfaces
    used by identified actions
• For list of actions for E-Bookstore (see
  page 49-50)
• Produced and/or accessed e.g.,:
  – Stock management functionality produces
    Stock database
  – Customer order data used in the first step of
    the Query Late Books scenario by the Goal
    step “Determine delivery status”
• Identify any external sources of required
  data (see page 50-51)
    Checking for Completeness and
• Names should be consistent
• All goals must be covered by scenarios, as a
  – step or trigger
  – by mentioning all it’s sub-goals
  – By mentioning parent goal
• All percepts and actions must covered by
• This preferably automated check should also
  draw attention to developer to things that might
  have been overlooked

Shared By:
fanzhongqing fanzhongqing http://