From Natural Language Requirements to Executable Models of Software Components

1

• From Natural Language Requirements to Executable
  Models of Software Components

2

• Barrett R. Bryant
• Beum-Seuk Lee
• Fei Cao
• Wei Zhao
• Carol C. Burt
• Jeffrey G. Gray
• Rajeev R. Raje
• Andrew M. Olson
• Mikhail Auguston

3
UniFrame Process
4
Key Issues
Define a process for construction of
heterogeneous distributed systems from
pre-existing components who advertise functional
and non-functional contracts for quality
assurance.

• Distributed Resource Discovery - component
  specification for deployment and location on the
  network
• Architecture-based Interoperability generation
  of glue/wrapper code to connect heterogeneous
  components
• Validation of Quality Requirements
  specification of Quality of Service contracts of
  components

5
Possible Solutions

• Unified Meta-Component Model (UMM) - informal
  specification of component functional and
  non-functional contracts
• Two-Level Grammar (TLG) formal specification
  language for describing UMM and domain-specific
  information
• Model Driven Architecture (MDA) model-based
  interoperability among heterogeneous components

6
Current Work
7
ATM - Requirements Document
Bank keeps list of accounts. It verifies ID and
PIN giving the balance and updates the balance
with ID. An account has three data fields ID,
PIN, and balance. ID and PIN are integers and
balance is a real number. ATM has 3 service
types withdraw, deposit, and balance check. For
each service first it verifies ID and PIN from
the bank giving the balance. ATM withdraws an
amount with ID and PIN giving the balance in the
following sequence. If the amount is less than or
equal to the balance then it decreases the
balance by the amount. And then it updates the
balance in the bank with ID. ATM deposits an
amount with ID and PIN giving the balance in the
following order. It increases the balance by
amount and then updates the balance in the bank
with ID. ATM checks the balance with ID and PIN
giving the balance.
8
ATM - Requirements Document in XML
ltdocumentgt ltpgt ltsgtBank keeps list of
accounts.lt/sgt lt/pgt ltpgt ltsgtIt verifies ID and PIN
giving the balance in the following order.lt/sgt
ltsgtIt selects the account from the list of
accounts where the ID of the account is
equal to the ID and the PIN of the account is
equal to the PIN.lt/sgt ltsgtAnd then it
assigns the balance of the account into the
balance.lt/sgt lt/pgt ltpgt ltsgtIt updates the balance
with ID in the following sequence.lt/sgt . . .
. . lt/documentgt
9
Natural Language Processing
10
Two-Level Grammar

• Syntax

class Class_Name. Data_Name , Data_Name
Data_Type , Data_Type. Rule_Name Rule_Body
, Rule_Body. end class.

• Example

class Account. Id, PIN Integer. Balance,
Amount Float. withdraw Amount
Amount lt Balance, Balance Balance - Amount.
deposit Amount end class.

• Properties

• Natural-language-like syntax Flexibility
• Formal notation Formalism
• Object-oriented structure Abstraction
• Logic/Functional operation Computation

11
ATM Two-Level Grammar
class ATM. Balance, Amount Float. ID,
PIN Integer. withdraw Amount with ID and
PIN Bank verify ID and PIN giving
Account, Account withdraw Amount.
deposit Amount with ID and PIN Bank
verify ID and PIN giving Account, Account
deposit Amount. check balance with ID and PIN
giving Balance Bank verify ID and PIN
giving Account, Account getBalance
Balance. end class.
12
ATM Vienna Development Method
class ATM instance variables private
bank Bank operations public withdraw
real int int gt void withdraw
(amount, ID, PIN) (dcl account Account
account bank . verify (ID, PIN) account
. withdraw (amount) ) public deposit
real int int gt void deposit (amount,
ID, PIN) (dcl account Account
account bank . verify (ID, PIN) account .
deposit (amount) ) public checkBalance
int int gt real checkBalance (ID,
PIN) (dcl account Account
account bank.verify (ID, PIN) return account
. getBalance () ) end ATM
13
System View
14
ATM - Unified Modeling Language (UML)
15
Model Driven Architecture

• OMG initiative for interoperating between
  different component technologies
  (http//www.omg.org/mda)
• Application logic of components conforming to
  some domain specification is expressed as a
  Platform Independent Model (PIM)
• PIM is converted into a Platform Specific Model
  (PSM) using a specific component technology

16
Problems

• Application domain logic is typically expressed
  in natural language (NL)
• Automated tools are needed to develop the domain
  specifications from the NL requirements
• Transformation from PIMs to PSMs should also be
  automated or semi-automated, based upon
  technology domain knowledge
• Models must consider not only functional aspects
  of domain logic, but also non-functional
  properties (i.e., Quality of Service QoS)

17
Video Streaming Naval Application
18
(No Transcript)
19
Model Transformation

• Aspect-oriented approach enhanced with TLG
  formalism
• Augment Abstraction with Separation
• Generate PSM by weaving separated PIM level
  modules together with various domain knowledge

20
Model Transformation
Domain knowledge (Technology,etc..)
PIM
Aspect Weaver
PSM
21
Approach Merits

• Natural language as the starting point for
  developing the business domain models
• Sufficient automation that components may be
  modified at the model level or even the natural
  language level as opposed to the code level
• Complement MDA with formal methods and QoS
• Targeting the construction of heterogeneous
  distributed software systems by the automated
  generation of glue/wrapper code elicited from
  technology domain knowledge

22
Acknowledgements

• This research was supported by U. S. Army
  Research Laboratory and U. S. Army Research
  Office Grant DAAD190-00-1-0350 and U. S. Office
  of Naval Research Grant N000014-01-01-0746.

23
Webpage

• http//www.cis.uab.edu/UniFrame