Capabilities, Plans, and Events Each capability is further broken down either into further capabilities or, eventually into the set of plans that provide.

Slides:



Advertisements
Similar presentations
Design by Contract.
Advertisements

FIPA Interaction Protocol. Request Interaction Protocol Summary –Request Interaction Protocol allows one agent to request another to perform some action.
BIS 360 – Lecture Seven Process Modeling (Chapter 8)
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Interaction Diagrams.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
1 Introduction to modeling Process modelling. 2 Where are we? #TitleDate 1Introduction ORM modeling Relational modeling
OASIS Reference Model for Service Oriented Architecture 1.0
Java Programming, 3e Concepts and Techniques Chapter 4 Decision Making and Repetition with Reusable Objects.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Systems Analysis and Design in a Changing World, Fourth Edition
UI Standards & Tools Khushroo Shaikh.
CS 582 / CMPE 481 Distributed Systems
PROCESS MODELING Transform Description. A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
ICS 463, Intro to Human Computer Interaction Design: 3. Perception Dan Suthers.
BPMN An Introduction ISIS. © ILOG, All Rights Reserved 2 Definition of BPMN Business Process Modeling Notation provides:  The capability of defining.
Task analysis 1 © Copyright De Montfort University 1998 All Rights Reserved Task Analysis Preece et al Chapter 7.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
Systems Analysis I Data Flow Diagrams
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
Chapter 7: The Object-Oriented Approach to Requirements
Click to add text © 2010 IBM Corporation Business Analytics software Using Cognos HTS for Report Review and Approvals.
Interaction Modeling. Sequence Models  There are two kinds of sequence models: scenarios and sequence diagrams  A scenario is a sequence of events that.
IT323 - Software Engineering 2 Tutorial 1. 0 The system 1.0 A Function 1.1 Activity of the function Task Task Task 1.2 Another activity.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
Requirements II: Task Analysis. Objectives By the end of the class, you will be able to… Write detailed task descriptions to inform design. Create scenarios.
1 ECCF Training 2.0 Platform Specific Model (PSM) ECCF Training Working Group January 2011.
Master Data for SCM (1) Master Data in Demand Planning & Fulfillment Processes EGN 5346 Logistics Engineering (MSEM, Professional) Fall, 2013.
Introduction to Sequence Diagrams
Chapter 8: Actor-System Interaction Modeling
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
System Specification Specify system goals Develop scenarios Define functionalities Describe interface between the agent system and the environment.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Lecture 5: Writing the Project Documentation Part III.
The Prometheus-ROADMAP Methodology Lin Padgham in collaboration with Leon Sterling and Michael Winikoff School of Computer Science and IT, RMIT University,
7 Systems Analysis and Design in a Changing World, Fifth Edition.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Understanding Task Analysis
1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011.
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
Strategic Management (Overview) Dr. Fred Mugambi Mwirigi JKUAT.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
CMPS 435 F08 These slides are designed to accompany Web Engineering: A Practitioner’s Approach (McGraw-Hill 2008) by Roger Pressman and David Lowe, copyright.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Network Protocols Network Systems Security Mort Anvari.
Java Programming, 2E Introductory Concepts and Techniques Chapter 4 Decision Making and Repetition with Reusable Objects.
Implementing Agent Systems Roughly speaking, there are three platforms: 1.Those that focus on internal agent reasoning and support plans, goals, etc. 2.Those.
Copyrighted material John Tullis 12/16/2015 page 1 04/08/00 MQ Series Middleware Presentation John Tullis DePaul Instructor
Systems Analysis and Design in a Changing World, Fourth Edition
CS3773 Software Engineering Lecture 06 UML State Machines.
Internal and Confidential Cognos CoE COGNOS 8 – Event Studio.
Operating Systems (CS 340 D) Dr. Abeer Mahmoud Princess Nora University Faculty of Computer & Information Systems Computer science Department.
UML - Development Process 1 Software Development Process Using UML.
Fusion Design Overview Object Interaction Graph Visibility Graph Class Descriptions Inheritance Graphs Fusion: Design The overall goal of Design is to.
Specifying the Interactions Builds on agent types and scenario descriptors Interaction Diagrams( IDs) involve –Replacing each functionality with the agent.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
Application Analysis. Application Interaction Model The purpose of analysis is to understand the problem so.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Systems Analysis and Design in a Changing World, Fourth Edition
Information Delivery Manuals: Process Mapping
Chapter 10: Process Implementation with Executable Models
BPMN - Business Process Modeling Notations
Presentation transcript:

Capabilities, Plans, and Events Each capability is further broken down either into further capabilities or, eventually into the set of plans that provide the details of how to react to situations, or achieve goals Capability Overview Diagram –Capability internals (may contain nested capabilities) –Plans –Messages (note: one of the incoming messages to a plan needs to be identified as the triggering message) Figure 9.1 on page 111, shows a capability diagram for the Stock managing capability of the Stock Manager agent-since this capability is fairly large, we break it down into three smaller capabilities: Ordering, Delay handling and Handling new stock. Figure 9.2 shows the plans that realize the Ordering capability

Sub-tasks and Alternative Plans At the lowest level of detail, each incoming message to the capability must have one or more plans that respond to that message Each plan is broken down into a number of sub- tasks, each of which is represented by an internal message – see page Initially, one plan per sub-task is sufficient Each plan is triggered by a specific event (i.e., a percept, message from other agent, internal message, or sub-task within agent.

Context Conditions specify the conditions or situation under which the various plans are applicable Often represents information about the state of the environment, which makes the plan suitable for use in that situation, e.g., –A plan to recompense a customer for a lost book by immediately sending a new book may have as a context condition that the required book is in stock. An alternative plan may provide the customer with a refund and have as a context condition that the book is not in stock Representation of necessary context conditions helps ensure the correct functioning of the agent – see bottom of page 114

Coverage refers to the concept of whether, for a given event, there will always be some plan with a matching context condition Do careful analysis to ensure that there is no gap in coverage –If no plan/response in some situations, identify how this is handled by the implementation platform (e.g., some define an “empty” plan)

Overlap refers to whether it is possible, in some situations, to have more than one plan that is applicable, necessitating a choice between them. There are two mechanisms by which this can happen: –When two context conditions overlap, that is, there is some situation in which both could be true simultaneously –Where the context condition contains variables that can potentially take on multiple values at a single point in time, leading to multiple plan instances of a single plan type Preferred plan can be controlled by platform, and/or at implementation time

Events Specify the information type, and allowable values, carried by each event. If some done earlier (as part of percept or message specification), refine it and expand on it. E.g., If there is a book order event, as a min info about book, and who ordered must be carried. As a plan is being developed the rest of the info will emerge. –For messages between agents, specify whether a reply is expected, and the details of it –Events representing percepts from the environment must specify the info carried as part of the percept See middle of page 117

Action, Percept, Data, and Plan Detail design should consider source –If it is non-agent, consider its notation and/or methodology (e.g., may involve use of API) –For data, consider Relational Schemas, Object Models, etc. Plan descriptors provide for an identifier, the triggering event type, context conditions, plan steps, messages, and list of data used/produced (data lists should be tied to particular data descriptors rather than being generic descriptors) and more – see middle page 119)

Check for Completeness and Consistency Completeness –Does it implement the required functionality? Are all messages required for its specified participation in protocols generated and received? –Ensure that all data is used/produced, and messages sent/received Consistency between final design artifacts –Overview Diagrams (bottom of page 121) –Between Overview Diagrams and Descriptors –Scenarios, Processes and Plan Sets –Processes consistent with Protocols and Overview Diagrams –Design “walk through” of key scenarios