V. Ambriola V. Gervasi Dipartimento di Informatica University of - - PowerPoint PPT Presentation

• V. Ambriola
• V. Gervasi

Dipartimento di Informatica University of Pisa - Italy

Vincenzo Ambriola: ambriola@di.unipi.it Vincenzo Gervasi: gervasi@di.unipi.it Web site: http://circe.di.unipi.it

Mapping the Requirements Country A general overview of CIRCE Natural language in CIRCE A few software models Integrating LyeeTM and CIRCE Conclusions

• Mapping the Requirements Country

Mapping the Requirements Country A general overview of CIRCE Natural language in CIRCE A few software models Integrating LyeeTM and CIRCE Conclusions

“Requirements engineering is the branch

• f software engineering concerned with

the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution

• ver time and across software families”
• P. Zave, 1997

Technical world:

Functions Constraints Precise specifications

Human world:

Cognitive psychology Anthropology Sociology Linguistics

RE, a discipline of description What is the best way to describe…

the system’s goals, constraints, etc. to different people (user, developers…) and tools (design checkers, verification tools…)

Time to go Greek!

Epistemology (what do the stakeholders believe?) Phenomenology (what can I observe in the world?) Ontology (what has objective existence?)

Requirements elicitation

Who has the information I need? How can I obtain that information?

Requirements modeling and analysis

How can I represent the information I got? What analysis can I perform on the information?

Requirements communication

What is the best way to communicate that information to different people, for different purposes?

Requirements agreement

Do we agree on those requirements? If not, how can we reach an agreement?

Requirements evolution

The world is changing: how can I adapt the requirements? My needs are changing: how can I adapt the requirements?

Building formal models of relevant entities:

Organization/Business/Enterprise models Information/Data models Behavior/Procedure models Domain models Constraints models Performance (non-functional) models

(cont’d) Formal models can be analyzed

To measure attributes and predict features

• f the final system

To check the consistency of the models

Many conceptual and technological tools, e.g.:

Requirements animation Model checking

Requirements “travel” back and forth among many parties Each party may prefer a certain language (due to different skills and goals) Requirements must be managed and traced across all those translations Requirements must be identifiable in different formalisms

Mapping the Requirements Country

• A general overview of CIRCE

A general overview of CIRCE Natural language in CIRCE A few software models Integrating LyeeTM and CIRCE Conclusions

IRCE

Analyze natural language* requirements Build formal models of

a requirements document the system described by the requirements the requirements development process

Present those models (visualization) Check them (validation) Measure their attributes (metrication)

* English and Italian currently implemented

IRCE

(domain-based)

“Ten seconds after the system has received a Launch Confirmation Command from Main Control, it shall set the main engine on, until the current altitude reaches the cruise altitude.”

actatpit untilact tspanafterevt tspan 10 secs set system Main engine ON receives gt Current altitude Cruise altitude system LCC Main control

“Ten seconds after the system has received a Launch Confirmation Command from Main Control, it shall set the main engine ON until current altitude reaches cruise altitude.”

Functional:

• a data flow carrying LCC exists from Main

Control to our system

• a data flow carrying “ON” commands exists from
• ur system to the main engine
• Validation: “current altitude” and “cruise altitude”

must be either built-ins or received from some source

• Metrics: this requirement specifies operations that

imply a certain complexity for our system

Main control LCC Main Engine altitude Cruise altitude ON Altimeter > GPS time position

• ld pos.

heading Maneuver Engine target pos. Cruise control command

Main control Main Engine Altimeter GPS Missile Control System MCS Diagnostics Maneuver Engine

“Ten seconds after the system has received a Launch Confirmation Command from Main Control, it shall set the main engine ON until current altitude reaches cruise altitude.”

Behaviour:

• A complex temporal ordering of events is

described

• Validation: events for which the system

waits should eventually happen

• Metrics: this requirement specifies
• perations that imply a certain complexity

for our system

Idle Waiting Engine on Engine off

LCC received from Main control 10 seconds elapsed Current altitude reaches cruise altitude

CIRCE can observe process events Document and system attributes can be traced during the evolution of the requirements Collection of process profiles Process guidance as outcome of validation

A “good” process: functional and behavioural complexity grows with time, validation violation are kept under control.

An instable process: functional and behavioural complexity oscillate, validation violation are addressed

• nly at the end of the process

IRCE

Mapping the Requirements Country A general overview of CIRCE

• Natural language in CIRCE

Natural language in CIRCE A few software models Integrating LyeeTM and CIRCE Conclusions

Universal: can express any model or property Shared: stakeholders from different backgrounds can communicate using NL Ease of experimentation: “early” requirements as matter for thought Good as a process unit: sentences are the right “atoms” for analyzing RE processes

(cont’d) Arbitrary abstraction level: requirements can be vague or precise without having to change language Most used in common industrial practice (despite the remarkable progresses of formal methods)

Designations

Identify entities in the domain Assign a name and establish synonyms

Definitions

Explain how a certain language should be interpreted

Requirements

Use designation, definitions, and basic language to express relationships among entities in the domain

Designations

Participant, is a user of the system participating to a meeting. Also “user”. Terminal, is a device for wireless

• communication. Also “mobile phone”.

Definitions Requirements + domain description statements

“Alert someone” means “send an SMS to his/her terminal”. Every user has a mobile phone. Two hours before a scheduled meeting, the system shall alert the participants to the meeting.

Designations Basic language Real world Definitions Requirements User language

Use domain-specific knowledge in parsing natural language sentences Replaces or supplements “traditional” grammar Terms are tagged with their domain- specific properties (semantic classes) POS-tagging may also be used

Rule-based rewriting system Rule matching can be imperfect (allows information extraction applications):

Missing terms Order inversions Extra terms

Backtracking and scoring system to select “best” parse tree Language-independent (but tested only on western languages)

Designations

IRCE

Participant/HUMAN: user. Terminal/IN/OUT: mobile phone.

Definitions Requirements + domain description statements

ALERT x/HUMAN -> send an SMS to $x’s terminal. Every user has a mobile phone. Two hours before the time scheduled for a meeting, the system shall alert all the participants to the meeting.

d. If the ACS N1S2 Cabin Pressure FDIR State is equal to ENABLED, then upon receipt of ACS N1S2 Cabin Pressure HW Data less than the Node 1 Cabin Pressure Lower Limit (initial: 13.9 psia) for 3 consecutive acquisitions, the NCS shall within 1.1 seconds: 1) Set the ACS N1S2 Cabin Pressure Lower Limit Warning State (initial value: FALSE) to TRUE, and 2) Issue a warning level alarm (message: “Node 1 Cabin Pressure Lower Limit Warning Violation”) in accordance with the section on “annunciate alarms”.

(NASA requirements for the ISS)

DEPC RELOP DEPT EVTFORSPAN DOOP CONDRECEIPT TSPAN TSPAN CONJ SET STANDARDEF SECTION WITHIN CP FDIR state equals CP HW data NCS Warning level alarm TRUE CP Lower Limit Warning state “Node 1 Cabin Pressure Lower Limit Warning violation” “Annunciate alarms” secs 1.1 Less than CP Lower Limit 3 sampling ENABLED ISSUEMSG UNITVAL DEFAULTVAL CP Lower Limit 13.9 psia DEFAULTVAL CP Lower Limit Warning state FALSE

IRCE

Designations, definitions and requirements can be “discovered” concurrently, or They can be extracted from a more rigorous process:

Domain analysis designations Language analysis definitions Problem analysis requirements

Basic language plays a key role

A software system (and its world) is modeled as a set of communicating, active

• r reactive agents

Things can have attributes, state, relationships Sense of Time Computational abilities

/EVT: an observable event/condition /ACT: an action performed by an agent /FUN: an action performed by an identifiable agent (actions are generally also events, for those observing them)

IF cond/EVT THEN/0 action/ACT agent/* function/FUN ( /EVT/ACT)

/IN, /OUT: can perform input & output /IRQ, /RIRQ: can request & accept interrupt requests /INF: a piece of information

/BLTIN: a constant, built-in table or self- generated info (e.g., random numbers) /… a few others

sender/OUT SENDS data/INF TO receiver/IN ( /ACT) client/IN/OUT QUERIES server/IN/OUT FOR data/INF

/ELAB: can perform computations /UNOP: unary operator /BINOP: binary operator /RELOP: relational operator

agent/ELAB COMPUTES result/INF USING parameter/INF agent/ELAB APPENDS item/INF TO collection/INF

/ENTITY: (optional) entity participating in relationships /REL: name of relationship /ATTR: attribute of something else /NUM: number, cardinality for relationships (literals predefined)

ent1/* relation/REL ent2/* attribute/ATTR OF ent/* ( /INF)

/HASSTATE: has an observable state

/ELAB: state is mutable, i.e. the object can voluntarily change its state

/MODE: name for a state

• bject/HASSTATE/ELAB BECOMES state/MODE

STATE OF object/HASSTATE ( /INF)

• bject/HASSTATE IS IN/0 state/MODE

( /EVT)

/PIT: a point in time, i.e. a definite instant /TSPAN: a time span, i.e. a certain length

• f time

/TINTERV: a time interval, i.e. the time between two definite moments

n/NUM SECONDS ( /TSPAN) span/TSPAN AFTER event/EVT ( /PIT)

Mapping the Requirements Country A general overview of CIRCE Natural language in CIRCE

• A few software models

A few software models Integrating LyeeTM and CIRCE Conclusions

Describes entities in the real world and their relationships Basic concepts:

Entities Attributes Relationships (static and dynamic) Selection

Entities can have attributes Every attribute of a certain entity has a value (/INF) Attributes can be inter-dependant (e.g., substance and weigth) Attributes can be hierarchical:

The weigth of the payload of a truck The value of the payload of a truck The max capacity of a truck truck

payload max capacity value weigth

Entities can be related through relationships Relationships have a cardinality They can be traversed (according to cardinality) Relationships can be

Static (immutable) Dynamic (depending

• n some data

structure)

A few well-known relationships:

IS-A, PART-OF,… truck person

• wner

driver

0..* 1 1

A particular instance from a class of similar entities Relation-based selection

… the truck driven by John Smith … the owner of a certain truck

Attribute-based selection

… all the drivers

• lder than 32

… any truck with a max capacity higher than 6 tons

Navigability: not all selections are valid

Ambiguity

“the truck of John Smith” – driven or owned by John?

Navigability

The truck driven by John – ok The truck owned by John – bad, John may own several trucks All the trucks owned by John – ok All the trucks driven by John – bad, John may only drive one truck at a time truck person

• wner

driver

0..* 1 1

“…the company of a certain truck”

Interpreted as: “…the company that employes the person that drives a certain truck”

Chains can extend to arbitrary length, as long as there is no scope for ambiguity and all the relations traversed are navigable Reflect common language shorthands

truck person

driver

1 1

company

employee

Tracks passage of data and computations Basic concepts:

Computational agents Data stores Attributes Computations (algorithms, formulae) Operators (functions and relational

• perators)

Agents interact by

exchanging data interrupting others

Agents can operate

• n data

executing algorithms and computing new values computing operators

• rder

stock confirmation

Data stores act as variables / records / repositories / data bases They can be internal data or represent (reify) real-world entities Attributes treatement

truck

payload max capacity

truck

payload payload

• rder

Real world Reified data

/INF

Variable or record

/INF/BLTIN (built-in)

Value is constant or generated

/INF/USDIN (used-in)

Usage is implicit (e.g., hardware register)

/INF/STABLE

Does not propagate updates

/INF/SIGNAL

Pure event, no information content

• rder

timer alarm model abort

Computation agent, parameters and result are specified Algorithms and formulae are not specified (abstraction) Algorithms, formulae, functions and

• perators are given a name, but no

definition Dual approach w.r.t. LyeeTM; scope for synergy.

Updates to data stores trigger further actions:

Computing dependant data stores Checking dependant conditions Transmitting values to the external world

Conditions that were false may become true

Generates new events

Combining data dependencies with explicitly-declared dependencies

Requirements are thoroughly validated with respect to DF consistency

Every data store must be either /BLTIN, or receive a value from at least a flow Every data store must be either /USDIN, pass its value to at least a flow, or be used in a condition test … and many similar properties

Specifies how agents act and react Basic concepts:

Event Condition Action Dependency (premise consequence)

CIRCE has a single concept for event and condition – something that can be true or false Context defines what is an event and what is a condition

If … then … (condition) When … (event)

Event-Condition-Action

WHEN the event becomes true, AS LONG AS the condition holds, PERFORM the action

Event-Action

WHEN the event becomes true, PERFORM the action

Condition-Action

AS LONG AS the condition holds, PERFORM the action

Action

PERFORM the action (continuously)

X A named event occurs X An entity enters a certain mode X An entity is in a certain mode X A specified point in time occurs X A predicate is true on some data item X Performing a named action X X Performing a named function X X Switching to a new mode X Receiving an interrupt request X X Causing an interrupt request on some other agent X X Performing a computation X X Requesting a value from a partner X Receiving a value from a sender X X Sending a value to a receiver

Act Evt Operation

A number of other models are treated or synthesized in CIRCE:

Finite state automata (FSA) Software Cost Reduction tables (SCR) Time models (TIME) Interaction sequences (SEQ)

We do not discuss these models in this presentation

CIRCE synthesizes a number of UML models:

Class diagrams Sequence / Interaction diagrams State diagrams

Skeleton code can be generated systematically from these models Experiences with generation of Java code

Deployment, components, etc. Not available! Interaction and statechart diagrams Dependencies & control Standard operations Data flows & comms. Classes, objects, and actors Agents & structured data UML NL & models entities

“If the meeting is not schedulable, the system shall send a warning message to the user that called the meeting.”

System Meeting

bool isSchedulable()

User

void recvWarning()

1 called by

“If the meeting is not schedulable, the system shall send a warning message to the user that called the meeting.”

:System :User :Meeting

r:=isSchedulable() [~r] recvWarning()

NL parsing Model building XMI export UML synthesis

Mapping the Requirements Country A general overview of CIRCE Natural language in CIRCE A few software models

• Integrating

Integrating Lyee LyeeTM

TM and CIRCE

and CIRCE Conclusions

Mapping the Requirements Country A general overview of CIRCE Natural language in CIRCE A few software models Integrating LyeeTM and CIRCE

• Conclusions

Conclusions