Project Name ProCom@MDH Version: 2.

0
Requirements Definition Date: 2010-01-09

MedhatwalMatrimony.com
Requirements Definition

Version 1.0

Page 1

Doc. No.:
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

Revision History
Date Version Description Author
2010-08-11 0.1 Initial Draft PG

Page 2
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

Table of Contents
1. Introduction 4
1.1 Purpose of this document 4
1.2 Intended Audience 4
1.3 Scope 4
1.4 Definitions and acronyms 4
1.4.1 Definitions 4
1.4.2 Acronyms and abbreviations 4
1.5 References 4

2. Requirements Description 5
2.1 Introduction 5
2.2 General requirements 5
2.3 Specific requirements 5

3. Use Case Models 7

3.1 Use case model 7
3.1.1 Actors 7
3.1.2 Generate Code 8
3.1.3 Compile Code 8
3.1.4 View Code 9

4. Requirements Definition 9
4.1 Requirement Group Definitions 9
4.2 Requirement Sources 9
4.3 Requirements definitions 10
4.3.1 Change Log 10

5. Future Development 11

Page 3
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

1. Introduction

1.1 Purpose of this document

The purpose of this document is to collect, analyze, and define high-level needs and features of
MedhatwalMatrimony.com. It focuses on the capabilities needed by the target users, and why these
needs exist. The nature of this report is kept as simple as possible so that the issues can be understood
by the audience.

1.2 Intended Audience

This document gives an overview to the audience about the requirements, what exactly is expected out
of the project. It includes:
• Customer
• Steering group
1.3 Scope
This document contains working and concepts implementation for our system. The specifications
provided in this document are based on a preliminary system analysis, and are not final.

1.4 Definitions and acronyms

1.4.1 Definitions

Keyword Definitions

1.4.2 Acronyms and abbreviations

Acronym or
Definitions
Abbreviation

1.5 References

2. Requirements Description

2.1 Introduction
ProCom model is part of PROGRESS project, developed at Mälardalen University, which is
used for formal modeling of embedded systems. ProCom@MDH enables user to generate
executable code for the ProCom models created in ProgressIDE. To generate executable code,
a mapping of ProCom models should be defined and a ProgressIDE plug-in for transforming
models to code should be created.
Page 4
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

2.2 General requirements

The ProCom plug-in is required to perform transformation between ProCom model, defined
using ProgressIDE, and the executable code. Transformation should not only include the
Components (as defined in section 2.3.x), but also the glue code, for the Connectors (as
defined in section 2.3.x). It is assumed that ProgressIDE generates an error-free XML file
which is to be transformed to the executable code. Parsing of XML file is part of the ProCom
plug-in, this should be extensible to include validation of XML schema later. User should be
provided with different options regarding the generation of code, such as, saving file,
choosing location, etc. Firstly the code generation of stand-alone Components should be
investigated and later the glue code generation.

2.3 Specific requirements

2.3.1 Design Elements of ProCom Model:

The ProCom Model consists of the following elements:
1) ProSys: ProSys contains subsystem. Subsystem contains other subsystem. Thus, the
model is hierarchical. Subsystems are components conforming to the ProSys Component
model. They can be further classified as:
 Primitive Subsystem: Primitive components are modeled by ProSave
components. Componentization activity is required to make code developed
outside PROGRESS context compatible with PROGRESS.
 Composite Subsystem: Composite subsystem internally consists of primitive
subsystems and these subsystems are connected by message channels
2) ProSave: In ProSave, a subsystem is constructed by hierarchically structured,
interconnected components. Components are passive and activation is always triggered at
the subsystem level. During deployment and realization process. Components are
transformed into executable units. Components contain ports and attributes. They can be
further classified as:
 Primitive components: Primitive components are the basic units of the ProCom
design model. They are realized by code containing C header function and C
source file where init function and service entry functions are defined.
 Composite Components: Composite components consist of sub-components,
connectors and connections. Each subcomponent is an instance of a primitive or
composite component developed either from scratch or it can be reusable piece
of component. The connectors and connections control the order in which
components are invoked and how data exchange takes place.

3) Ports: Ports are part of subsystems and can be of two types:

 Input message port
 Output Message port

4) Message channel: Ports of ProSys subsystem are connected via the message channels.
They support n-to-n communication i.e. several input and output ports can be connection
to the same channel.

5) Services: The functionality of a ProSave component is made available to external entities

by a set of services. Each service corresponding to a particular functionality provided by
the component. A service typically consists of the following parts:

Page 5
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

 Input port group

 Output port group.
Each port group consists of the following two types of ports:
 Trigger port: A components service is activated by an external entity using the
trigger port.
 Data ports: These ports receive and contain data required to perform a service.
Data ports are typed and associated with a default value used for initialization.

6) Connections: Components interact with each other to provide complex functionality

using either connections or connectors. A connection is a directed edge which connects
two ports- input data port to output data port or input trigger port to the output trigger
port. They determine the data and control flow.

7) Connectors: Connectors are used to control the data and control flow between two or
more components. Connectors can be further classified into several types namely:
 Data fork: Splits a data connection to several ports
 Data or: Merges several data connections to one
 Control fork: Splits control flow to several concurrent paths
 Control or: Merges several control flow to one
 Control join: Joins the control flow of several concurrent paths
 Selection: Chooses a path of a control flow depending on a condition

8) Clock: A clock is used for generating periodic triggers. It consists of a single output
trigger port which is triggered at a specified rate.

2.3.2 Requirement Description:

The following sets of requirements should be addressed by ProCom@MDH:
1. ProCom Model Transformation: All the elements discussed in the above section are used to
design the ProCom model for an embedded system. The transformation of all the individual
elements to their corresponding source code is the most essential part of the requirement. This
initial requirement would not cover the interaction between these elements rather will focus on
their code generation as stand alone elements. The generated code should be checked for its
syntactic correctness through code compilation. Any error in compilation should be notified to
the user as “Failure of Code Generation” action.

2. Glue Code Generation: Once the code mapping of all the ProCom elements is achieved, glue
code should be generated for the system. Glue Code defines interaction between different
components of a system. The code files generated after the glue code generation should be
compiled to check for their syntactic correctness. Any error in compilation should be notified
to the user as “Failure of Glue Code Generation” action. If time doesnot permit, a document
should be made for the possibility of glue code generation.

3. Plug-in Development: The functionality of the model transformation and the glue code
generation should be provided either in a new user interface or in the existing ProgressIDE
interface. The user interface and the functionality developed for code generation should be
packaged in a plug-in for the ProgressIDE. The compatibility of the plug-in with the
ProgressIDE should be checked.

Page 6
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

4. Implementation Case Study: Once all the above sets of requirement are covered, the
complete package should be implemented on a case study. The case study should validate the
correct functioning of the plug-in and accurate code generation for the ProCom elements.

5. Refine XML Schema: Suggest any changes required in the existing XML, and document
those changes.

3. Use Case Models

3.1 Use case model

3.1.1 Actors
User: The designer creating ProCom model.
System: ProCom plug-in or ProgressIDE

3.1.2 Generate Code

Initiator:
User
Goal:
To generate the code from ProCom model.

Main Scenario:
Page 7
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

1. User creates a ProCom project.

2. User develops a model of the system using ProgressIDE.
3. User selects the model to generate code.
4. User selects “Generate code” option from menu.
5. System redirects the user to the code generation option menu.
6. User browses the location for code.
7. System will generate the code for model.
8. In this generated code, there is a file named as MainProgram.java. This contain
the main() method of java serves as starting point of code execution.
9. System adds the generated code for the model in into tree view.

Extensions:
1. If code generation fails then system displays error message.
2. If model is invalid then code generation will not start and system displays error
message.
3. At any point, user decides to close the ProgressIDE. System saves all data and
exits.

3.1.3 Compile Code

Initiator:
User
Goal:
To compile the generated code from ProCom model.

Pre-requisite:
There should exist a valid ProCom model in the Progress IDE, for which code is
generated.

Main Scenario:
1. User selects Code Compilation option from the menu.
2. System shows the user the Code Compilation interface.
3. User selects the option to compile the code or defer it.
4. System performs Code compilation.

Extensions:
1. If compilation fails then, system displays error message.
2. At any point, user decides to close the ProgressIDE. System saves all
data and exit.

3.1.4 View Code

Initiator:
User

Goal:
To view the generated code from ProCom model.

Page 8
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

Pre-requisite:
There should exist a valid ProCom model in the Progress IDE, for which code is
generated

Main Scenario:
1. User selects the generated code file to View code from navigation pane.
2. User selects the editor to View code.
3. System redirects the user to the view code option menu.
4. System shows the generated code.

Extensions:
1. If system fails to show code, system displays error message.
2. At any point, user decides to close the ProgressIDE. System saves all
data and exit.
3.1.5 Execute Code

Initiator:
User
Goal:
To execute the compiled code from ProCom model.

Pre-requisite:
In order to perform code execution, there has to be at least one prosys component.

Main Scenario:
1. User creates the DLL files used for native C call from Java.
2. User copies two files (One is implemented C file and one DEF file to
the defined path).
3. User selects Generate DLL File option.
4. User selects Executed Code option.
5. System performs Code execution.
6. System stores the result in antrun.log
7. User views antrun.log for final output

Extensions:
1. If code execution fails then, system displays error message in
antrun.log.
2. If generate DLL fails then, system displays error message in antdll.log.
3. At any point, user decides to close the ProgressIDE. System saves all
data and exit.

4. Requirements Definition

4.1 Requirement Group Definitions

Identification Requirement Group Rem.

PCT ProCom Model Transformation
Page 9
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

GCG Glue Code Generation

PID Plug-In Development
CS Case Study

4.2 Requirement Sources

Source Description Rem.

Customer Ivica, Ana
Developer ProCom Team

4.3 Requirements definitions

Identity Sta Prio Description Source

tus rity
ProCom Model transformation
PCT1 I 1 Code Generation for the Primitive Subsystem Customer
PCT2 I 1 Code generation for the Composite Subsystem Customer
PCT3 I 1 Code Generation for the Primitive ProSave Component Customer
PCT4 I 1 Code Generation for the Composite ProSave Component Customer
PCT5 I 1 Code Generation for the Connection Subsystem Customer
PCT6 I 1 Code Generation for the Input Message port Customer
PCT7 I 1 Code Generation for the Output Message port Customer
PCT8 I 1 Code Generation for the Message Channel Customer
PCT9 I 1 Code Generation for the Connection(s) Customer
PCT10 I 1 Code Generations for the Connector(s) Customer
PCT16 I 1 Code Generation for ProSave Clock Customer
PCT17 I 2 Compilation of the generated code Customer
PCT18 A 2 Execution of the compiled code Customer
PCT19 A 2 Compiling of Dll files, manual for ProCom designer Developer

Glue Code Generation

GCG1 D 1 Glue Code Generation for the Primitive Subsystem Customer
GCG2 D 1 Glue Code generation for the Composite Subsystem Customer
GCG3 D 1 Glue Code Generation for the Primitive ProSave Component Customer
GCG4 D 1 Glue Code Generation for the Composite ProSave Component Customer
GCG5 D 1 Glue Code Generation for the Connection Subsystem Customer
GCG6 D 2 Compilation of the generated glue code Customer
GCG7 A 2 Possibility of Glue Code Generation Customer

Plug-In Development
PID1 I 1 Interaction with ProgressIDE Customer
Page 10
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

PID2 I 1 Development of User Interface Customer

PID3 I 2 Code Viewing Customer

Case Study
CS1 I 2 Validation on a case study. Customer

Requirement status:
I = initial (this requirement has been identified at the beginning of the project),
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = additional (this requirement was introduced during the project course).

4.3.1 Change Log

Acti
Identity Date Comments
on
GCG1-6 D 2010-01-08 Identify the possibility of Glue code generation in a doc
GCG7 A 2010-01-08 Documentation along with other mapping doc
PCT18 A 2009-12-05 Missed out in initial requirement gathering
PCT19 A 2009-12-10 Native C Call

Requirement status:
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = added (this requirement was introduced during the project course).
R = resurrected (dropped or on hold requirement was reactivated)

5. Future Development
ProgressIDE is a research based project. Over a period of time, enhancements and modifications can be
made to the code generation model. There can be possible validation of schema, multiple profiles for
code generation or class diagram view as discussed below:

1. Schema Validation
For now, it is assumed that ProgressIDE generates a error-free XML file which is to be transformed to
the executable code. Parsing of XML file is part of the ProCom plug-in, this should be extensible to
include validation of XML schema later.

2. Multiple Profiles
Possibility of generation of C code from the ProCom model can be investigated and implemented.
Page 11
Project Name ProCom@MDH Version: 2.0
Requirements Definition Date: 2010-01-09

3. Class view representation

Functionality to generate Class diagram view of the designed ProCom model can be provided.

4. Reverse Engineering
Functionality can be provided to generate ProCom model design from the Java code.

5. Glue Code Generation & Threading

For now, the possibility of glue code is documented on an example model using Java RMI calls. This
can further be enhanced. Also the threading implementation is very naïve, and every component should
execute on its own thread in ideal mapping. Since this might complicate the understanding of code for
the user, we have neglected it.

Page 12