1

Advanced Information Systems Development (SD3043)

Trends in System DevelopmentTrends in System Development

2

A historical view• 1963-1968

– The emerging software crisis

• 1968-1970– Birth of software engineering

The most important goals were to get control of the software development process and to improve software performance and software reliability

3

What changed? Did it help?• The introduction of software engineering led to

– New approaches and techniques to the management of software development

• The introduction of software engineering helped to– Better understand the issues involved in the

development of systems

– Successfully build large, reliable systems

4

Software Development challenges

• Shorter development lifecycles• More ambitious requirements• Less certain requirements• More challenging environments

– Dynamic systems– Open systems– Security issues

5

Dealing with the challenges• Better processes

– Faster development

– Light methods

• Better models– Abstractions

– Architectures

– Components

Agile Development

Agent Oriented Software Engineering

6

Agile Development

• Agile methods are a family of development processes, not a single approach to software development.

• The Agile Manifesto states:• We are uncovering better ways of developing software

by doing it and helping others do it. Through this work we have come to value:– Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan

7

Principles behind the Agile Manifesto

• Customer satisfaction by rapid, continuous delivery of useful software

• Working software is delivered frequently (weeks rather than months) • Working software is the principal measure of progress • Even late changes in requirements are welcomed • Close, daily cooperation between business people and developers • Face-to-face conversation is the best form of communication (co-

location) • Projects are built around motivated individuals, who should be

trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances

8

Agile development approaches

• AM – Agile Modelling– Agile Modeling (AM) is a practice-based methodology for effective

modeling and documentation of software-based systems.   At a high level AM is a collection of best practices.  At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.  http://www.agilemodeling.com/e

– XP – Extreme Programming– Extreme Programming is a discipline of software development based

on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation

9

Extreme Programming • XP is a novel combination of elements of best practice in systems

development• First publicized by Kent Beck (Beck, 2000)• Known for its use of pair programming but has other important

aspects• Underlying principles

– Communication - XP highlights the importance of good communication among developers and between developers and users.

– Simplicity - XP focuses on the simplest solution for the immediate known requirements.

– Feedback - Feedback in XP is geared to giving the developers frequent and timely feedback from users and also in terms of test results. Work estimates are based on the work actually completed in the previous iteration.

– Courage - Urges the developer to throw away code that is not quite correct and start again. Essentially the developer has to leave unproductive lines of development despite personal investment in the ideas.

10

Extreme Programming

• XP also emphasises:– embracing change is important and key to

systems development– development staff are motivated by

producing quality work

11

Requirements Capture in XP

• Based on user stories that describe the requirements– written by the user– basis of project planning and the development of test

harnesses

• Very similar to use cases though some proponents of XP suggest that there are key differences in granularity– typical user story is about three sentences with no

technology indicated– Developers get detailed descriptions from the customer

when they start developing

12

XP Activities• The planning game involves quickly defining the scope of

the next release from user priorities and technical estimates. The plan is updated regularly as the iteration progresses.

• The information system should be delivered in small releases that incrementally build up functionality through rapid iteration.

• A unifying metaphor or high level shared story focuses the development.

• The system should be based on a simple design.• Programmers prepare unit tests in advance of software

construction and customers define acceptance tests.• The programme code should be restructured to remove

duplication, simplify the code and improve flexibility—this is known as refactoring, and is discussed in Fowler (1999) in detail.

13

Using XP

• Best suited to projects with a relatively small number of programmers—say no more than ten

• Critical to maintain clear communicative code and to have rapid feedback– If these are not possible then XP would be

problematic

• XP not sympathetic to using UML for analysis & design

14

References about XP• Extreme Programming explained, Kent

Beck, (005.1 BEC – library)

• http://www.extremeprogramming.org/index.html

• Extreme programming for Web projects, Wallace et al., (005.72 – Library)

• Various web pages

15

Agent Oriented Software Engineering

Agent Oriented Software Engineering (AOSE) introduces an alternative approach in analysing and designing complex distributed computerised systems, according to which a complex computerised system is viewed as a multiagent system in which a collection of autonomous software agents interact with each other in order to satisfy their design objectives

16

Agents

• A software surrogate for an end user or a process that fulfills a stated need or activity

– Uses built-in and learned knowledge base to make decisions and accomplish tasks in a way that fulfills the intentions of a user

– Also called software robots or bots• “An agent is anything that can be viewed as perceiving

its environment through sensors and acting upon that environment through effectors,” (from Russell and Norvig, Artificial Intelligence: a Modern Approach)

17

What is an Agent?• The main point about agents is they are

autonomous: capable of acting independently, exhibiting control over their internal state

• Thus: an agent is a computer system capable of autonomous action in some environment in order to meet its design objectives

SYSTEM

ENVIRONMENT

input output

18

Wooldridge & Jennings (Wooldridge, 1995) Definition

• A hardware or (more usually) software based computer system that enjoys the following properties:– Autonomy

• Agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state

– Social Ability• Agents interact with other agents (and possibly humans) via some

kind of agent communication language– Reactivity

• Agents perceive their environment, (which may be the physical world, such as a user via a graphical user interface, a collection of other agents etc), and respond in a timely fashion to changes that occur in it

– Pro-activeness• Agents do not simply act in response to their environment, they are

able to exhibit goal directed behaviour by taking the initiative– http://www.csc.liv.ac.uk/~mjw/pubs/iee-review96.pdf

19

Multiagent Systems

• The true power of the agent paradigm is realised from the use of multiagent systems.

• Contain more than one agent

• A task is divided into a set of subtasks and distributed amongst the different agents of the system

20

Few Types of agents• Many different ways to classify agents

– According to tasks they perform• Information gathering• Information filtering• Personal assistants

– According to their properties• Intelligent

– Demonstrates some kind of intelligence

• Learning– Changes its behaviour according to previous experience

• Mobile– Able to transport itself from one machine to another

21

Features of Intelligent Agents• An intelligent agent has mental properties, such

as knowledge, belief, intention, obligation. In addition, and agent has other properties such as:– mobility: agents can move around from one machine to another

and across different system architectures and platforms;– veracity: agents do not knowingly communicate false

information;– benevolence: agents always try to do what they are asked of;– rationality: agents will try to achieve their goals and not act in

such a way to prevent their goals from being achieved.– learning/adaptation: agent improve performance over time

22

Application of Agent-based computing - I

It can solve new problems.• Openness. When components of the system are not

known in advance, change over time, and are highly heterogeneous (e.g. programming the Internet) an agent-based approach allows to create systems that are flexible, robust, and can adapt to the environment by using their social skills, ability to negotiate with other agents, and ability to take advantage of opportunities.

• Complexity. With large and complex problems, agents offer a natural way to partition the problem into smaller and simpler components, that are easier to develop and maintain, and are specialized.

23

Application of Agent-based computing - II

• Natural Metaphor. Agents provide an easy way to conceptualize metaphors. For instance, an e-mail filtering program can be presented using the metaphor of a personal digital assistant. This could also cause problems if the reasoning done by the agent is a black box to the user.

• Legacy systems. Modifying existing software to keep pace with changing needs is often impossible. Legacy software can be incorporated into agent-based software by building an “agent wrapper” around it, to allow it to cooperate and communicate with other agent-based software.

• http://agents.umbc.edu/introduction/jennings98.pdf

24

User Interface Agents

– Interface Tutors – observe user computer operations, correct user mistakes, provide hints/advice on efficient software use

– Presentation Agents – show information in a variety of forms/media based on user preferences

– Network Navigation Agents – discover paths to information, provide ways to view it based on user preferences

– Role-Playing – play what-if games and other roles to help users understand information and make better decisions

25

Information Management Agents

– Search Agents – help users find files and databases, search for information, and suggest and find new types of information products, media, resources

– Information Brokers – provide commercial services to discover and develop information resources that fit business or personal needs

– Information Filters – Receive, find, filter, discard, save, forward, and notify users about products received or desired, including e-mail, voice mail, and other information media

26

Agents versus Objects• Objects are inactive most of the time and become active only when

another object requires their services. In contrast, a software agent is continually active, sensing its environment and selecting the actions to perform

• The object paradigm does not address issues like cooperation, competition, negotiation and so on, which form the foundation for multi-agent systems development

• Agents are able to judge their results and modify their behaviour (their internal structure) according to these results and their goals, while objects are not able of doing so

• In objects, messages are method invocations while agents define different types of messages and use complex protocols to negotiate

• For objects to communicate, “public” methods are used. Any other object has the right to invoke a public method from any object that contains one. In contrast an agent can decide if it will perform an action (method) that belongs to it or not.

27

Reasons for justify OO methodologies in developing agent systems

• According to Iglesias (Iglesias, 1999)– Similarities between the main two concepts

– Common usage of object oriented languages (e.g. JAVA)

– Familiarity of many software engineers with object oriented methodologies

– Both emphasize the importance of interactions between the entities of the system

28

Shortcomings of extending OO

methodologies • The level of abstraction and the models

provided by OO are not adequate to model agent characteristics– Autonomous, have intentions

• Not adequate set of concepts and mechanisms for complex systems

“… for complex system we find that objects, classes and modules provide an essential yet insufficient means of abstraction” (Booch, 1994)

29

Shortcomings of OO methodologies

• The object model fails to capture the dynamic nature of the interactions between the agents

• Fail to capture the social behaviour of agents• Fail to model the mental states (goals, tasks, capabilities)

of the agents of the system

So? Can we use them?• Agent Oriented methodologies are necessary but the

work on them can adopt, where suitable, existing methods and take advantage of the work done so far

30

AOSE now• Agent systems development is currently

dominated by informal guidelines rather than formal principles and well-defined engineering techniques

• Very few formalized techniques exist to support different stages of AOSE

AOSE is still in its infancy

31

Some AOSE methodologies• GAIA

– Jennings (Southampton), Wooldridge (Liverpool), Zambonelli (Modena)

• MaSE - Multiagent Systems Engineering

– Scott A. Deloach (Kansas)

• Tropos– Mylopoulos (Toronto), Giorgini (Trento), Mouratidis

(UEL)

© H. Mouratidis

32

GAIA• One of the first methodologies specifically tailored to the analysis and design

of agent-based systems.

• It views the requirements phase as separate of the analysis and design phase.

• The key concepts in Gaia are roles, which have associated with them responsibilities, permissions, activities, and protocols. Roles can interact with one another in certain institutionalised ways, which are defined in the protocols of the respective roles

Requirements Statement

Roles Model

Interactions Model

Agent Model

Services Model

Acquaintance Model

Analysis

Design

http://www.csc.liv.ac.uk/~mjw/pubs/jaamas2000b.pdf

33

MaSE• It provides support for generating code using the MaSE

code generation tool. • UML diagrams have been modified in order to model

notions of agents as well as their cooperative behaviour.

Domain Level

Design

Domain Level

Design

Agent Level Design

Agent Level Design

Component Design

Component Design

System Design

System Design

Start

End

http://people.cis.ksu.edu/~sdeloach/publications/Conference/mase-aose2000.pdf

34

Tropos• The most important feature of Tropos is

that it aspires to span the overall software development process, from the early requirements to implementation

• Uses concepts such as actors, goals, tasks, resources and social dependencies that define obligations from one actor to another

35

Tropos stages• Early requirements: identify domain stakeholders and model them

as social actors who depend on each other. Possible to state the why!

• Late requirements: Model the dependencies of the system with other actors (functional and non-functional requirements)

• Architectural Design: define the system’s architecture and identify the agents of the system

• Detailed Design: Specify agent capabilities and interactions

Early Requirement

s

Early Requirement

s

Late Requirement

s

Late Requirement

s

Architectural Design

Architectural Design

Detailed Design

Detailed Design

Start

End

36

Pitfalls of agent development (Wooldridge, 2004)

• Oversell agent solutions, or fail to understand where agents might be usefully applied– Do not understand its limitations

• Get religious or dogmatic about agents– Many applications still for which conventional software

engineering techniques are more appropriate• Do not know why you want agents

– Read optimistic reports about the technology and adopt it

• Believe that agents are the silver bullet– Hasn’t proved itself yet!

• Forget you are developing software– So software engineering good practice should be followed!

37

Pitfalls of agent development (Wooldridge, 2004)

• Design does not exploit concurrency– Do you really need agents?

• See agents everywhere– Develop a successful system using agents…then you

only think agents!• Have too few agents

– Do not recognise the advantages of multi agent systems

• Spend all your time implementing infrastructure– No widely used software platforms for developing

multiagent systems…spend effort and time for developing them

38

References / Reading • “An introduction to Multiagent Systems”,

Michael Wooldridge, Willey & Son, 2003

• “Software agents”, J. Bradshaw (006.3)

• “Readings in agents”, M. Hunhs et al. (006.5)

39

Summary

• Extreme Programming

• Agent Oriented Software Engineering