Trends in System Development

bouncerarcheryΤεχνίτη Νοημοσύνη και Ρομποτική

14 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

59 εμφανίσεις

1

Advanced Information Systems
Development (SD3043)


Trends 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 Agent
s


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

Agent Level
Design

Component
Design

System Design

Start

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
Requirements

Late
Requirements

Architectural
Design

Detailed Design

Start

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