1 Advanced Information Systems Development (SD3043) Trends in System Development Trends in System Development
Jan 11, 2016
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