Topic 3: Multi-Agent Systems in Software Engineering

1
Topic 3 Multi-Agent Systemsin Software
Engineering

• the unified process (UP)
• requirements / analysis / design
• architectural analysis

2
When do we consider MAS ?

• given a problem, how to solve it ?
• centralized systems
• distributed systems
• enhanced distributed systems (cat. 1)
• decentralized systems (cat. 2)
• a philosophy to solve a distributed problem
• where does this fit in the software engineering
  process ?

3
The Unified Process (UP)

• de facto standard software development process
• for building object-oriented systems
• aims
• high quality software
• meeting requirements
• manage projects

4
Basic principles

• clear distinction
• requirements / analysis research the problem
  domain
• design towards implementable entities
• implementation
• testing
• maintenance
• iterative development

5
UP Iterative development
Development cycle

• sequential waterfall life cycle
• Requirements paralysis
• Late feedback
• Overwhelming complexity

Requirements
implementation
Design
Testing
6
UP Iterative Development
Development cycle
Iteration
2-6 weeks
UP Disciplines
requirements
testing
design
implementation
7
UP Main Activities

• requirements / analysis
• research the problem domain
• domain modelling
• requirements analysis
• system sequence diagrams
• design towards implementable artefacts
• implementation

8
Requirements / AnalysisTypes of requirements

• typical categorisation
• functional requirements
• non-functional requirements
• functional requirements
• use case model
• non-functional requirements
• supplementary specifications

9
Requirements / AnalysisTypes of requirements

• Categorisation according to FURPS model
• Functional
• features, capabilities
• Usability
• human factors, help, documentation
• Reliability
• frequency of failure, recoverability
• Performance
• Response times, throughput, accuracy, resource
  usage
• Supportability
• Adaptability, maintainability, configurability
• Implementation
• Resource limitations, languages, tools, hardware
• Interface
• With external systems
• Packaging
• Legal

10
Requirements / AnalysisExample Use Case

• Handle Returns
• Main Success Scenario
• A customer arrives at a checkout with items to
  return. The cashier uses the POS system to record
  each returned item ...
• Alternate Scenarios
• If the credit authorization is reject, inform the
  customer and ask for an alternate payment method.
• If the item identifier is not found in the
  system, notify the Cashier and suggest manual
  entry of the identifier code (perhaps it is
  corrupted).
• If the system detects failure to communicate with
  the external tax calculator system, ...

11
Requirements / AnalysisDomain Modelling
Visualizing Concepts

• model concepts in a problem domain
• a representation of real-world things, not
  software entities
• it shows
• concepts
• associations between concepts
• attributes of concepts

12
Requirements / AnalysisDomain Models

• A Domain Model is a description of things in the
  real world
• A Domain Model is not a description of the
  software design
• A concept is an idea, thing, or object

13
UP Main Activities

• requirements / analysis
• research the problem domain
• design towards implementable artefacts
• design class diagram
• interaction diagrams
• design patterns
• implementation

14
Design

• class diagram basis for further implementation
• interaction diagrams
• sequence diagrams (focus on time sequence of
  messages)
• collaboration diagrams (focus on object
  interactions)
• design patterns
• reuse good design practice

1 message2()
message1()
2 message3()
ClassAInstance
ClassBInstance
15
UP Main Activities

• requirements / analysis
• study of the problem domain
• design towards implementable artefacts
• implementation

software architecture
16
Architectural Analysis
17
Architectures are influenced by system
stakeholders

• many stakeholders
• customers
• end users
• developers
• project managers
• system maintainers
• marketeers

software architect

• architects experience
• technical environment

18
Why is Software Architecture Important ?

• intellectually graspable model of the solution
• early design decisions
• communication among stakeholders

When to start architectural analysis ?

• before the first development!
• cover high risk factors
• e.g.
• must be internationalized to support English,
  Chinese and Hindi
• must handle 500 concurrent transactions with
  on-average one-second response time
• deferring these factors to late development is a
  recipe for pain and suffering

19
Architectural Analysis

• identification of
• non-functional requirementsin the context of
  functional requirements
• e.g. security for a sales application
• requirements
• non-functional requirements
• reliability / fault tolerance
• adaptability / configurability
• security
• many others
• memory utilization, network usage, modifiability,
  usability,
• and behaviour (functional requirements)

20

• common steps in architectural analysis
• identification of architectural drivers
• architectural solutions
• the science versus the art

21
(1) the scienceidentifying architectural drivers

• possible architectural drivers FURPS
  requirements
• functional
• usability
• reliability
• performance
• supportability
• sub-factors
• implementation (limitations, technologies)
• interface
• operations
• packaging
• legal
• quality scenarios
• quantifying (at least attempt to) architectural
  drivers
• to understand their
• influence
• priority

22
(2) the artresolving architectural factors

• recording architectural alternatives, decisions
  and motivations
• priorities
• examples of layered architectures
• virtual machines and operating systems
• layers of abstraction
• the three-tier architecture

23
Conclusion

• architectural analysis
• detailed requirements (functional
  non-functional)
• software architecture backbone of application
  design
• describes HOW the software solution will be built
• to meet the high-priority requirements

24
Conclusion for MAS

• MAS is in essence
• a solution strategy
• a basis for a software architecture
• for systems with high-priority to
  (non-functional) requirements such as
• flexibility
• reliability
• scalability
• in a
• distributed world
• very dynamic world
• ? flexible and adaptive to change
• NOT FOR FREE !
• owning a hammer does not make one an
  architect