1 / 24

Multi-Agent Systems in Unified Process: Requirements, Analysis, Design & Architectural Analysis

Explore Multi-Agent Systems (MAS) in software engineering using the Unified Process (UP). Learn about MAS philosophy, UP principles, iterative development, requirements analysis, domain modeling, design artifacts, implementation, and architectural analysis.

hinojos
Download Presentation

Multi-Agent Systems in Unified Process: Requirements, Analysis, Design & Architectural Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 / Analysis:Types of requirements • typical categorisation: • functional requirements • non-functional requirements • functional requirements • use case model • non-functional requirements • supplementary specifications

  9. Requirements / Analysis:Types 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 • Licencing

  10. Requirements / Analysis:Example 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 / Analysis:Domain 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 / Analysis:Domain 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. - distribution - complexity - requirements 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 • architect’s 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 science:identifying 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 • variability

  22. (2) the art:resolving 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”

More Related