software architectures as social structures - cs.toronto.edu filenthe kaos project defines the...

2001 Manuel Kolp and John Mylopoulos AWSA’01 -- 1

Software Architecturesas Social Structures

Manuel Kolp and John MylopoulosUniversity of Toronto

AWSA’01, Edmonton, AlbertaAugust 24-25, 2001


What is Software?

nA mathematical abstraction, a theory, which can beanalyzed for consistency and can be refined into a morespecialized theory (Mathematical perspective)nAn engineering artifact, which is designed, tested and

deployed using engineering methods; the methods relyheavily on testing and inspection for validation(Engineering perspective)nA non-human agent, with its own personality and

behavior, defined by its past history and structuralmakeup (CogSci perspective)nA social structure of software agents, who communicate,

negotiate, collaborate and cooperate to fulfil their goals(Social perspective)


…An Idea...

n Software Engineering methodologies havetraditionally come about in a “late-to-early” phase (or,“downstream-to-upstream”) fashion.

n In particular, Structured Programming precededStructured Analysis and Design; likewise, Object-Oriented Programming preceded Object-OrientedDesign and Analysis.

n In both cases, programming concepts were projectedupstream to dictate how software designs andrequirements are conceived.

n What would happen if we projected requirementsconcepts downstream to define software designsand even implementations?


Requirements Concepts?

n We distinguish between early and late requirements.n Early requirements are concerned with understanding

the organizational context within which the system-to-be will eventually operate.

n Late requirements focus on identifying (andmodeling) functional and non-functional requirementsfor the system-to-be.

n We turn to early requirements for inspiration... Laterequirements are so 20th century...


Early Requirements Concepts?

n The organizational environment of a software systemcan be conceptualized as a set of businessprocesses, actors and/or goals.

n The KAOS project defines the state-of-the-art onmodeling early requirements in terms of goals; alsooffers well-developed analysis techniques and toolsfor generating late requirements.

n We focus on actors and goals. In particular, we adoptthe i* framework of Eric Yu [Yu95].


Actors and their Goals

A social setting consists of actors, each having goals(and/or softgoals) to be fulfilled.

Participant Manager

Schedulemeeting Productive

meetings

Schedulemeeting

Low costscheduling

Good meeting


GoalAnalysis

Schedulemeeting

By all means By

email

-

- +

++

+

-

-

Collecttimetables

By person

Bysystem

Have updatedtimetables

Collectthem

Chooseschedule

Manually

Automatically

MatchingeffortCollection

effort

Minimalconflicts

Degree ofparticipation

Quality ofscheduleMinimal

effort


Actor Dependencies

Throughpersonal contact

By email

CollecttimetablesSchedule

meetingScheduleSchedulemeetingmeeting

Reception

System


Actor Dependency Models

AttendMtg

UsefulMtg

CalendarInfo

SuitableTime

Scheduler

Participant

ScheduleMtg

ContributeToMtg Initiator


Using These Concepts

n During early requirements, these concepts are used tomodel external stakeholders (people, organizations,existing systems), their relevant goals and inter-dependencies.

n During late requirements, the system-to-be enters thepicture as one or a few actors participating in i*models.

n During architectural design, the actors being modelledare all system actors.


Late Requirements with i*

Initiator

AttendMtg

UsefulMtg

CalendarInfo

SuitableTime

SchedulerParticipant

ScheduleMtgSystem

Timetablemanager

Reporter

ManageCalendarInfo

MtgInfo

ContributeToMtg


Software Architectures with i*

CalendarInfo

Timetablemanager

Reporter

CollectCalendarInfo

UpdateMtgInfo

Processquery

Updater

Retriever

InfoGatherer

System

RetrieveMtgInfo


What is Different?

n Goal refinement extends functional decompositionmethods in the sense that it explores alternatives.

n Actor dependency graphs extend object interactiondiagrams in that a dependency is monitored and maybe discarded, also it can be established at run-time.

n In general, an actor architecture is open and dynamic;evolves through negotiation, matchmaking and like-minded mechanisms.

n The distinction between design and run-time isblurred.

n So is the boundary between a system and itsenvironment (software or otherwise.)


Why is this Better (…Sometimes…)

n Traditionally, goals (and softgoals) areoperationalized and/or metricized before laterequirements.

n This means that a solution to a goal is frozen intoa software design early on and the architect hasto work within the confines of that solution.

n This won’t do in situations where the operationalenvironment of a system, including itsstakeholders, keeps changing.


Architectural Styles Revisited

n If the nature of the building blocks of softwarearchitectures changes, so should the relevant designstyles

n Where do we turn for ideas?üTry organizational theory for (more-or-less)

tightly structured actor networks;üMore generally, try social theory (social

networks, communities and the like); see workby Jarke et al;


An Architectural Style: Structure-in-5

Accounts for the strategic and logistic components found inorganizations.

nn Operational coreOperational core: responsible for basic operations -- theinput, processing, output associated with running theorganization.

nn Strategic apexStrategic apex: executive, strategic decisions.nn SupportSupport: Assists the operation core for non-operational

services outside the basic flow of operational procedures.nn TechnostructureTechnostructure: standardizes the behavior of other

components, helps the system adapt to its environment.nn Middle lineMiddle line: Actors who join the apex to the core.


Structure-in-5Meta-schema


Joint Venture

n More decentralizeddecentralized and open than structure-in-5.nn AgreementAgreement between 2+ principal partnerspartners (PPs) to

obtain the benefits derived from operating at a largerlargerscale and reusingreusing the experience and knowledge of thepartners.

n PPs are autonomous on a local dimensionlocal dimension and interactwith other PPs to exchange services, data andknowledge.

nn StrategicStrategic operation and coordination (global dimensionglobal dimension)delegateddelegated to a joint managementjoint management actor, whocoordinatescoordinates tasks and manages the sharingsharing ofservices, knowledge and resources.

nn OutsideOutside the joint venture, secondary partnerssecondary partners supplyservices or support tasks for the organization core.


JointVentureMeta-

Schema


Potential Applications

n Consider agent-based systems and the foothold theyare gaining in (web-based) eCommerce softwarepractice.

n Or, consider Application Service Providers and theidea that a software application is composeddynamically from a number of externally providedservices.

n Or, consider peer-to-peer (P2P) computing where thestakeholders of a P2P network are defineddynamically and at run time, also services aredeveloped bottom up by “factoring out” commonlyperformed tasks and common interests/goals amongpeers.


Tropos

n Adopt i* to support modeling and analysis from earlyrequirements to detailed design.

n We are developing a formal Tropos language (inspiredby KAOS) to augment i* diagrams.

n Developing a set of analysis techniques for Tropos,including temporal analysis (using model checking),goal analysis, and (…soon…) social structure analysis.

n Also developing a methodology which supportssoftware development from early requirements todetailed design.

n This is a long-term project with most of the researchwork ahead of -- rather than behind -- us.(http://www.cs.toronto.edu/km/tropos)

software architectures as social structures - cs.toronto.edu filenthe kaos project defines the...

Documents