 2001 John Mylopoulos STRAW’01 -- 1 Software Architectures as Social Structures John Mylopoulos University of Toronto First ICSE Workshop titled “From.

Slides:



Advertisements
Similar presentations
1 GRL Introduction Lin Liu University of Toronto April 2001.
Advertisements

Dept of Information and Communication Technology Tropos' Tropos at the Age of 6: Status and Research Directions John Mylopoulos University of Trento.
ECOE 560 Design Methodologies and Tools for Software/Hardware Systems Spring 2004 Serdar Taşıran.
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Using the Semantic Web to Construct an Ontology- Based Repository for Software Patterns Scott Henninger Computer Science and Engineering University of.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Agent-Oriented Software Engineering and Tropos Agent-Oriented Software Engineering Early Requirements and i* Modeling with i* Formal Tropos Analyzing Formal.
The Role of Software Engineering Brief overview of relationship of SE to managing DSD risks 1.
Introduction To System Analysis and Design
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
SIM SOFTWARE ARCHITECTURE Instructor: Masrah Azrifah Azmi Murad, PhD Room: C masrah.azrifah [at] gmail.com OR masrah [at] fsktm.upm.edu.my.
Information Modeling: The process and the required competencies of its participants Paul Frederiks Theo van der Weide.
© Copyright Eliyahu Brutman Programming Techniques Course.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Goal.
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
AOSE-2003, Melbourne July 15 th 1 Agent Oriented modeling by interleaving formal and informal analysis Anna Perini 1, Marco Pistore 2,1, Marco Roveri 1,
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Logical Architecture and UML Package Diagrams
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
A Requirement-Driven Development Methodology Jaelson Castro † Manuel Kolp ‡ John Mylopoulos ‡ ‡ Department of Computer Science University of Toronto University.
Introduction To System Analysis and design
The Software Development Life Cycle: An Overview
UML - Development Process 1 Software Development Process Using UML (2)
ARTIFICIAL INTELLIGENCE [INTELLIGENT AGENTS PARADIGM]
Unit 2: Engineering Design Process
Requirements Analysis
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
SecureTropos ST-Tool A CASE tool for security-aware software requirements analysis Departement of Information and Communication Technology – University.
TC Methodology Massimo Cossentino (Italian National Research Council) Radovan Cervenka (Whitestein Technologies)
A Goal-Based Organizational Perspective on Multi-Agent Architectures Manuel Kolp † Paolo Giorgini ‡ John Mylopoulos † † Department of Computer Science.
1 From GORE (not the US presidential candidate) to AORE (Agent-Oriented Requirements Engineering) Eric Yu University of Toronto November 2000.
Introduction To System Analysis and Design
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Exploring the Intentional Dimension during Software (Architecture) Design adding the “why” and the “who/where” to the “what” and the “how” Daniel Gross.
Chapter 7: A Summary of Tools Focus: This chapter outlines all the customer-driven project management tools and techniques and provides recommendations.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
10 Software Architecture CSCU 411 Software Engineering.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
 1999 John Mylopoulos Requirements-Driven IS Engineering -- 1 Requirements-Driven Information System Engineering John Mylopoulos University of Toronto.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Requirement Engineering for Trust Management : Model, Methodology Reasoning P. Giorgini, F. Massacci, J. Mylopoulos, N. Zannone, “Requirements Engineering.
Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design,
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
ATAL - Seattle, August 1 st, A Knowledge Level Software Engineering Methodology for Agent Oriented Programming The Tropos framework Fausto Giunchiglia.
ATAL - Seattle, August 1 st, A Knowledge Level Software Engineering Methodology for Agent Oriented Programming The Tropos framework Fausto Giunchiglia.
1 Evolving System Architecture to Meet Changing Business Goals An Agent and Goal-Oriented Approach Daniel Gross & Eric Yu Faculty of Information Studies.
1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
 The need for a formal methodology description  SPEM for describing an agent oriented methodology  PASSI: an example  The needed extension  Discussion.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
WEB 2.0 PATTERNS Carolina Marin. Content  Introduction  The Participation-Collaboration Pattern  The Collaborative Tagging Pattern.
1 From Conceptual Models to Simulation Models Takashi Iba* Yoshiaki Matsuzawa** Nozomu Aoyama** * Faculty of Policy Management, Keio University ** Graduate.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Prof. Hany H. Ammar, CSEE, WVU, and
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013.
Systems Architectures System Integration & Architecture.
SECURE TROPOS Michalis Pavlidis 8 May Seminar Agenda  Secure Tropos  History and Foundation  Tropos  Basics  Secure Tropos  Concepts / Modelling.
Model Checking Early Requirements Specifications in Tropos Presented by Chin-Yi Tsai.
Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN
Detecting Conflicts of Interest
Agent-oriented Software Engineering Methodologies
Presentation transcript:

 2001 John Mylopoulos STRAW’ Software Architectures as Social Structures John Mylopoulos University of Toronto First ICSE Workshop titled “From Software Requirements to Architectures” (STRAW’01) Toronto, May 14, 2001

 2001 John Mylopoulos STRAW’ …An Idea... Software Engineering methodologies have traditionally come about in a “late-to-early” phase (or, “downstream-to-upstream”) fashion. In particular, Structured Programming preceded Structured Analysis and Design; likewise, Object- Oriented Programming preceded Object-Oriented Design and Analysis. In both cases, programming concepts were projected upstream to dictate how designs and requirements are conceived. What would happen if we projected requirements concepts downstream to define software designs and even implementations?

 2001 John Mylopoulos STRAW’ Requirements Concepts? We distinguish between early and late requirements. Early requirements are concerned with understanding the organizational context within which the system-to- be will eventually operate. Late requirements focus on identifying (and modeling) functional and non-functional requirements for the system-to-be. We turn to early requirements for inspiration... Late requirements are so 20th century...

 2001 John Mylopoulos STRAW’ Early Requirements Concepts? The organizational environment of a software system can be conceptualized as a set of business processes, actors and/or goals. The KAOS project defines the state-of-the-art on modeling early requirements in terms of goals; also offers well-developed analysis techniques and tools for generating late requirements. We focus on actors and goals. In particular, we adopt the i* framework of Eric Yu [Yu95].

 2001 John Mylopoulos STRAW’ Actors and their Goals A social setting consists of actors, each having goals (and/or softgoals) to be fulfilled. Participant Manager Schedule meeting Productive meetings Schedule meeting Low cost scheduling Good meeting

 2001 John Mylopoulos STRAW’ Goal Analysis Schedule meeting By all means By Collect timetables By person By system Have updated timetables Collect them Choose schedule Manually Automatically Matching effort Collection effort Minimal conflicts Degree of participation Quality of schedule Minimal effort

 2001 John Mylopoulos STRAW’ Actor Dependencies Through personal contact By Collect timetables SchedulemeetingSchedulemeeting Reception System

 2001 John Mylopoulos STRAW’ Actor Dependency Models Initiator ContributeToMtg AttendMtg UsefulMtg CalendarInfo SuitableTime Scheduler Participant ScheduleMtg

 2001 John Mylopoulos STRAW’ Tasks vs Goals Tasks are processes for fulfilling goals. In general, there will be many tasks for fulfilling a single goal. When actors are assigned goals, they are (or, ought to be) equipped with means for fulfilling them by carrying out one or more tasks.

 2001 John Mylopoulos STRAW’ Goals vs Softgoals Goals come with a predicate which defines when they are fulfilled. Softgoals are “natural kinds” or “primitive terms” in the sense that they don’t have such a predicate. However, they can still be analyzed and the degree of their fulfillment can be evaluated in terms of other goals.

 2001 John Mylopoulos STRAW’ Using These Concepts During early requirements, these concepts are used to model external stakeholders (people, organizations, existing systems), their relevant goals and inter- dependencies. During late requirements, the system-to-be enters the picture as one or a few actors participating in i* models. During architectural design, the actors being modelled are all system actors.

 2001 John Mylopoulos STRAW’ Late Requirements with i* Initiator AttendMtg UsefulMtg CalendarInfo SuitableTime Scheduler Participant ScheduleMtg System Timetable manager Reporter Manage CalendarInfo MtgInfo ContributeToMtg

 2001 John Mylopoulos STRAW’ Software Architectures with i* CalendarInfo Timetable manager Reporter Collect CalendarInfo Retrieve MtgInfo Update MtgInfo Process query Updater Retriever InfoGatherer System

 2001 John Mylopoulos STRAW’ What is Different? Goal refinement extends functional decomposition methods in the sense that it explores alternatives. Actor dependency graphs extend object interaction diagrams in that a dependency is monitored and may be discarded, also it can be established at run-time. In general, an actor architecture is open and dynamic; evolves through negotiation, matchmaking and like- minded mechanisms. The distinction between design and run-time is blurred. So is the boundary between a system and its environment (software or otherwise.)

 2001 John Mylopoulos STRAW’ Why is this Better (…Sometimes…) Traditionally, goals (and softgoals) are operationalized and/or metricized before late requirements. This means that a solution to a goal is frozen into a software design early on and the architect has to work within the confines of that solution. This won’t do in situations where the operational environment of a system, including its stakeholders, keeps changing.

 2001 John Mylopoulos STRAW’ Architectural Styles Revisited If the nature of the building blocks of software architectures changes, so should the relevant design styles Where do we turn for ideas? Try organizational theory for (more-or-less) tightly structured actor networks (see [Kolp, this workshop]); More generally, try social theory (social networks, communities and the like); see work by Jarke et al;

 2001 John Mylopoulos STRAW’ Potential Applications Consider agent-based systems and the foothold they are gaining in eCommerce software practice. Or, consider Application Service Providers and the idea that a software application is composed dynamically from a number of externally provided services. Or, consider peer-to-peer (P2P) computing where the stakeholders of a P2P network are defined dynamically and at run time, also services are developed bottom up by “factoring out” commonly performed tasks and common interests/goals among peers.

 2001 John Mylopoulos STRAW’ Tropos Adopt i* to support modeling and analysis from early requirements to detailed design. We are developing a formal Tropos language (inspired by KAOS) to augment i* diagrams. Developing a set of analysis techniques for Tropos, including temporal analysis (using model checking), goal analysis, and (…soon…) social structure analysis.. Also developing a methodology which supports software development from early requirements to detailed design. This is a long-term project with most of the research work ahead -- rather than behind -- us.

 2001 John Mylopoulos STRAW’ Conclusions There is a fundamental difference between requirements -- which are basically intentional in nature -- and architectures -- which describe extensional structures and behaviours. Our proposal eliminates this difference altogether in the name of software malleability…...we don’t want to freeze any more solutions to a given requirement in the software designs we produce!!

 2001 John Mylopoulos STRAW’ What is Software? A mathematical abstraction, a theory, which can be analyzed for consistency and can be refined into a more specialized theory (Mathematical perspective) An engineering artifact, which is designed, tested and deployed using engineering methods; the methods rely heavily on testing and inspection for validation (Engineering perspective) A non-human agent, with its own personality and behavior, defined by its past history and structural makeup (CogSci perspective) A social structure of software agents, who communicate, negotiate, collaborate and cooperate to fulfil their goals (Social perspective)