COSMIC ISO 19761 is considered a second generation of functional size measurement methods. It has met its primary design goal to be of practical value in software project performance measurement and in estimating activities, both in research and industry. The method's partial and full automation -with very high accuracy results- helped in accelerating its adoption and widespread use. This paper presents a new approach for automatically and rapidly obtaining COSMIC functional size of Software requirements by introducing a new means to directly express and implement these requirements using the COSMIC vocabulary. An example is also presented as a proof of concept of the approach proposed.
The concept of Functional Size measurement (FSM) has become a key factor in Software management, hence it is crucial to be able to measure it accurately and eficiently. Automating FSM is important for organizations needing to measure a large number of projects within a short time frame, provided, of course, that the results automatically generated are accurate, particularly when such measurement is based on an international measurement standard.
The COSMIC FSM method [
Automating functional size measurement is a high-importance task when its reported benefits
and the potential for wider usage are considered. Despite the challenges, one can observe the
increasing number of studies that deal with automating COSMIC FSM [
This paper examines first the scientific literature covering topics related to the automation of COSMIC based FSM procedures using diferent Software artifacts, e.g.: source code, textual requirements or a models. Second, the implementation of a Source-to-Source compiler for a COSMIC programming language that acts as an executable binary, while also automatically obtaining the functional size without the need of any human intervention, is also presented in this paper.
This paper is organized as follows: Section 2 examines the literature review on COSMIC automation. Section 3 presents overviews of COSMIC, Compilers and Source-to-source compilers. Section 4 presents the proposed approach and its implementation. Conclusions follow in section 5.
This section presents the literature review of existing procedures and tools that automate
COSMIC FSM. Over 30 papers have matched the criteria of keywords related to automated
method or a tool for COSMIC functional software size. The search engine used for this review
is Google Scholar[
The study in [
The studies in [
The study in [
The study in [
The study in [
The study in [
The study in [
The study in [
The study in [
The study in [
The study in [
The study in [16] introduced the MENSURA tool, which integrates the COSMIC concepts and utilizes them for communicating what users need in terms that the developers could understand and allow to define specific units of size. [ 16] presented an approach of the automation of the software FSM through a tool that could be used in two periods: from the new outline requirements and once the requirements have been specified.
The study in [17] presented a guideline for measuring functional size in accordance with the COSMIC ISO 19761 measurement method for ECU Application Software designed following the AUTOSAR architecture.
The study in [18] proposed a three phase verification protocol for automation tools implementing the COSMIC-ISO 19761 measurement method. The proposed protocol uses the representation created to extract all the necessary information to obtain the functional size of the software to be measured using the COSMIC method, the example verification was of an AUTOSAR-based FSM automation prototype tool developed at ESTACA.
The study in [19] introduced an automation prototype tool in JAVA was developed at ESTACA. The inputs are SYMTA/S simulation files that include both AUTOSAR models and ECU processor load information. This tool makes it possible to measure automatically software functional size, in CFP, designed following the AUTOSAR methodology and meta-model.
The study in [20] introduced a script named e-Cosmic, and the core functionality of the script is it reports functional size of the software product from BPM.
The study in [21] presented a functional size measurement procedure called E-FSMP. E-FSMP applies the standard COSMIC measurement method to BPMN(Business Process Model and Notation) diagrams by means of the application of 11 rules. In addition, a tool that automates the application of E-FSMP has been presented. With this tool, measurement results can be obtained quickly and avoiding precision errors that commonly occurs with manual measurements.
The studies in [22] and [23] introduced UPROM tool which can be used to automatically generate COSMIC FSM using BPM.
The study in [24] presented an RPA (Robotic process automation). A robot from a banking operation was used to illustrate how the measurement of an RPA software can be made by using the COSMIC method by gathering functional user requirements from BPMN, proving the applicability of the COSMIC method measurement process to this type of software.
The study in [25] presented an approach and a tool for the automation of functional size
measurement with RUP. The design of this tool is based on the direct mapping between
COSMICFFP and UML concepts and notation. [
The study in [27] introduced an automated measurement tool that can generate COSMIC FSM from the XML representation of UML, SysML and Petri net by using generation model and mapping rules.
The study in [28] introduced J-UML COSMIC, a tool that supports the proposed measurement procedure from UML and simplifies project monitoring and control, because it automatically obtains accurate measurements.
The study in [29] proposed formal measurement rules for ROOM(Real-time Object Oriented Modeling language) specifications according to COSMIC-FFP informal definitions given in previous research.
The study in [30] introduced OOmCFP, which is an FSM procedure for object-oriented applications generated in MDA (Model-Driven Architecture) environments. OOmCFP allows the measurement of the functional size in the conceptual models that will be transformed in the generated applications.
The study in [31] proposed a COSMIC based functional size measurement (FSM) procedure for real time embedded software requirements documented using the Simulink modeling tool.
The studies in [32] and [33] proposed a procedure for measuring functional side of Synchronous Languages, which maps COSMIC method to LUSTRE programming language and the LUSTRE based SCADE model.
The study in [34] presented work that provides a first evidence of the viability of measuring requirements expressed via Problem Frames by means of the COSMIC FSM method.
The study in [35] introduced a procedure that maps ORM architecture with COSMIC, the proposed tool starts with resolving files and XML mapping files to identify the business domain objects, and then it finds presentation layer controls (buttons, textboxes, html-tags etc.), which have a triggering action and related events attached to these actions.
To our best knowledge, no COSMIC based programming language that also acts as a tool to measure COSMIC FSM directly from source code has been proposed proposed. The existing eforts made are semi-automatic external plugins dedicated for some languages to parse the code, and map each keyword to a COSMIC data movement.
The COSMIC method provides a standardized method for measuring the functional size of software from both the Management Information Systems domain and the real-time domain. The COSMIC method is considered a second generation FSM. This method has been accepted as an International Standard: ISO/IEC 19761 Software Engineering – COSMIC – A functional size measurement method (hereafter referred to as ISO 19761). The latest version of the COSMIC manual available on the COSMIC website is version 5.0. While this release includes a number of refinements, the original principles of the COSMIC method have remained unchanged since they were first published in 1999. The COSMIC method measures the Functional User Requirements (or FUR) of software. The result obtained is a numerical ‘value of a quantity’ (as defined by the ISO) representing the functional size of the software.
The COSMIC method divides the software’s Functional User Requirements (FUR) into four diferent types of data movements: • Entry (E): Data Group passing from functional user to a functional process. • Exit (X): Data Group leaving from a functional user to a functional process. • Read (R): Reading Data Group from persistent storage.
• Write (W): Writing Data Group into persistent storage.
The COSMIC measurement process has three phases: • The Measurement Strategy Phase • The Mapping Phase • The Measurement Phase Each phase has a dedicated purpose to help organize the process of FSM. The Measurement Strategy phase is about gathering FUR, and defining the purpose of the measurement. The second phase, the Mapping phase, is meant to map an artifact to the COSMIC Generic Software Model to identify Functional Processes and Data Movements. The third phase, the Measurement phase, is where the actual measurement in CFP (COSMIC Function Point) is done by summing up the number of data movements identified.
A compiler is system software that translates code written in a high-level programming language to a lower-level programming language.
A compiler is generally divided into two parts: Front end, and Back end. The front end has 3 stages: • Lexical Analysis: The source code is first read through, then separated into tokens, each of which corresponds to a programming symbol. • Syntax analysis: This phase organises the list of tokens generated in the preceding phase into a tree-structure called Abstract Syntax Tree (AST), which reflects the program’s structure. • Semantic analysis: This step examines the program’s AST to see whether it violates any of the program’s consistency constraints.
The back end has also 3 stages: • Intermediate code generation: The compiler generates a low level or machine like intermediate representation of the code. • Code optimization: The compiler optimizes that intermediate representation generated in the previous phase • Code generation: The compiler translates the optimized intermediate representation into targeted machine code.
A Source-to-Source compiler (also called Transcompiler, or Transpiler) translates a small subset of several programming languages into several others. It takes a lot of efort to write a comprehensive back-end for a language. If some generic intermediate representation (IR) to target machine code generator already exists, it can be used as a base for front end. Otherwise, a front end for a target language needs to be created, and instead of creating a back end that reduces the semantics to to primitive target machine code, it translates the original source code to another high level language that can use the existing tools of that language, as an alternate mean, which in this case is called a Source-to-Source compiler. It is basically a front end -Lexical and Semantic analysis- with a high level code translator only, instead of using an IR code generator.
The first step towards developing a compiler, is to decide on what set of compiler technologies to use. However, for the sake of practicality, we did not use any. A simple source-to-source compiler can be implemented with any plain programming language.
The COSMIC method is better suited to be mapped to a functional programming language, so that each functional process may be represented as a function. Mapping COSMIC FSM should be done in the semantic analysis phase, since it is when we have a full parsable Abstract Syntax Tree to identify the data movements of each functional process.
The main aim is to develop a language having a grammar and keywords in accordance with the COSMIC method, so that anyone who is familiar with the method can instantly recognize the pattern of the language, and start coding.
We used Node.js as the run-time environment of our source-to-source compiler. Node.js has many available modules that can eficiently help in developing the front-end part for the compiler.
As for the back-end of the Source-to-source Compiler, it was deemed more convenient to translate the source code into Javascript to instantly run on Node.js without the need of installing other modules.
A lexer and a parser are needed in the front-end. 4.1.1. Lexer The generated Lexer takes as input the original source code file of the CPL and generates the tokens to be later used by the parser. The lexer module used is Moo.js [36]. It is a lexer generator which is defined by specifying some regular expressions that define the tokens of the language. Moo.js is faster than other tokenizers and it complements the Nearley.js [37] parser, by enabling it to be instantly used. 4.1.2. Parsing The generated parser uses the tokens produced by the lexer, goes through the Semantic Analysis phase, and outputs an parsable AST. The parser module used is Nearley.js which is a streaming parser with support for catching errors gracefully and providing all parsings for ambiguous grammars. It is compatible with Moo.js. It comes with tools for creating tests, railroad diagrams and fuzzers from your grammars, and has support for a variety of editors and platforms. It works in both Node.js and the browser.
The compiler takes the AST generated by the parser, traverses it, and accordingly translates it to Javascript on a file, that is directly run on Node.js In programming, Error Reporting is needed. Syntax Errors are reported by the parser. Run-time errors are reported by Node.js as the back end runs entirely on Javascript.
A "Hello, world!" program is frequently used to demonstrate the appearance and feel of a programming language. The following is an example of a program written in the COSMIC programming language proposed in this paper: funcproc main() {
print("Hello, World!") } The CPL syntax can be summarized into these following statements:
#Comment • Declaration Statements: write varName = value varName = value #global variable #local variable • Conditional Statements:
if (condition) { #codeblock } • Loop Statements:
while (condition) { #codeblock } • Functional Process Definition Statements:
funcproc name (parameters) { #codeblock }
The measurement process is done after the parsing of the source code is done, and an AST is
generated, which is parsed to calculate the sum of CFP according to the following mapping
rules:• Identify 1 functional process (FP) for each defined function in the source file.
• Identify 1 Entry (E) for each data group in each parameter in a FP.
• Identify 1 Exit (X) for a return in a FP.
• Identify 1 Entry (E) for functional process call trigger.
• Identify 1 Entry (E) for main functional process call trigger.
• Identify 1 Read (R) for each global variable read.
• Identify 1 Write (W) for each global variable write.
• Aggregate the CFP for each data movement in a FP to obtain the size of the FP.
• Aggregate the CFP of each FP to obtain the size of the whole file.
4.5. Code Example
#write
write a = 100
#write
write b = 200
#write
write c = [
When applying the mapping rules to the code example, 3 global variable writes are identified, which in this case is our persistent storage, and 2 Functional processes foo() and main() are also identified. When a main FP is defined, we assume there is main FP call trigger. A main() functional process is needed to execute the code. The COSMIC size of the code is 3 (Global Definitions) + 4 (Foo()) + 13 (Main()) = 20 CFP.
As shown in Fig. 1, the compiler runs on Node.js, and takes the file "test.cpl", then parses it, according to the mapping rules, it displays each CFP rule as explained above, then sums it up displaying the total size in CFP. Lastly it automatically translates and runs the Javascript file to display the code output.
This paper proposed a programming language compiler based on COSMIC FSM, designed with COSMIC related keywords to be familiar to anyone using COSMIC FSM.
After reviewing the scientific literature on COSMIC automation, Compilers and the COSMIC method are discussed. Next, the approach towards how to map the COSMIC method to the
COSMIC programming language (CPL) compiler is presented. An example of the measurement of a CPL program was presented to better illustrate the mapping approach.
We believe our approach would allow professionals in the Software industry to do away with the need of using additional specific tools dedicated only for size measurement. Our approach would allow them to use a programming language to implement Software requirements, execute binaries and obtain systematically and automatically COSMIC function size in CFP.
In the future, we aim to further test the accuracy of the compiler. The language should be compared with other existing and in use languages to be able to identify missing features, to better develop the compiler and update the language with in need features to allow it to be used in more practical cases. management tool, in: Proceedings of the XIV Brazilian Symposium on Information Systems, 2018, pp. 1–8. [16] F. Valdés-Souto, Automated cosmic measurement through mensura® tool (????). [17] H. Soubra, K. Chaaban, Functional size measurement of electronic control units software designed following the autosar standard: A measurement guideline based on the cosmic iso 19761 standard, in: 2012 Joint Conference of the 22nd International Workshop on Software Measurement and the 2012 Seventh International Conference on Software Process and Product Measurement, IEEE, 2012, pp. 78–84. [18] H. Soubra, A. Abran, A. Ramdane-Cherif, Verifying the accuracy of automation tools for the measurement of software with cosmic–iso 19761 including an autosar-based example and a case study, in: 2014 Joint Conference of the International Workshop on Software Measurement and the International Conference on Software Process and Product Measurement, IEEE, 2014, pp. 23–31. [19] H. Soubra, A. Abran, M. Sehit, Functional size measurement for processor load estimation in autosar, in: Software Measurement, Springer, 2015, pp. 114–129. [20] M. Kaya, O. Demirors, E-cosmic: a business process model based functional size estimation approach, in: 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications, IEEE, 2011, pp. 404–410. [21] B. Marín, J. Quinteros, A cosmic measurement procedure for bpmn diagrams., in: SEKE, 2014, pp. 408–411. [22] B. Aysolmaz, O. Demirörs, Uprom tool: A unified business process modeling tool for generating software life cycle artifacts., in: CAiSE (Forum/Doctoral Consortium), 2014, pp. 161–168. [23] B. Aysolmaz, O. Demirörs, Unified process modeling with uprom tool, in: International
Conference on Advanced Information Systems Engineering, Springer, 2014, pp. 250–266. [24] F. V. Souto, R. Pedraza-Coello, F. C. Olguín-Barrón, Cosmic sizing of rpa software: A case study from a proof of concept implementation in a banking organization., in: IWSMMensura, 2020. [25] S. Azzouz, A. Abran, A proposed measurement role in the rational unified process and its implementation with iso 19761: Cosmic-fp, in: Software Measurement European Forum, Rome, Italy, 2004. [26] T. Zaw, S. Z. Hlaing, M. M. Lwin, K. Ochimizu, A Lightweight Size Estimation Approach for Embedded System using COSMIC Functional Size Measurement, Ph.D. thesis, MERAL Portal, 2017. [27] T. Zaw, S. Z. Hlaing, M. M. Lwin, K. Ochimizu, An automated software size measurement tool based on generation model using cosmic function size measurement, in: 2019 International Conference on Advanced Information Technologies (ICAIT), IEEE, 2019, pp. 268–273. [28] G. De Vito, F. Ferrucci, C. Gravino, Design and automation of a cosmic measurement procedure based on uml models, Software and Systems Modeling 19 (2020) 171–198. [29] H. Diab, M. Frappier, R. S. Denis, Formalizing cosmic-fp using room, in: Proceedings ACS/IEEE International Conference on Computer Systems and Applications, IEEE, 2001, pp. 312–318. [30] B. Marín, O. Pastor, G. Giachetti, Automating the measurement of functional size of conceptual models in an mda environment, in: International Conference on Product Focused Software Process Improvement, Springer, 2008, pp. 215–229. [31] H. Soubra, A. Abran, S. Stern, A. Ramdan-Cherif, Design of a functional size measurement procedure for real-time embedded software requirements expressed using the simulink model, in: 2011 Joint Conference of the 21st International Workshop on Software Measurement and the 6th International Conference on Software Process and Product Measurement, IEEE, 2011, pp. 76–85. [32] H. Soubra, Fast functional size measurement with synchronous languages: An approach based on lustre and on the cosmic iso 19761 standard, in: 2013 Joint Conference of the 23rd International Workshop on Software Measurement and the 8th International Conference on Software Process and Product Measurement, IEEE, 2013, pp. 3–8. [33] H. Soubra, L. Jacot, S. Lemaire, Manual and automated functional size measurement of an aerospace realtime embedded system: A case study based on scade and on cosmic iso 19761, International Journal of Engineering Research and Science & Technology 4 (2015). [34] V. Del Bianco, L. Lavazza, Applying the cosmic functional size measurement method to problem frames, in: 2009 14th IEEE International Conference on Engineering of Complex Computer Systems, IEEE, 2009, pp. 282–290. [35] B. Ozkan, Automated functional size measurement for three-tier object relational mapping architectures, Journal of Software Engineering 21 (2011) 311–338. [36] Moo.js, 2022. URL: https://github.com/no-context/moo. [37] K. Chandra, T. Radvan, nearley: a parsing toolkit for JavaScript, https://github.com/kach/ nearley, 2014. doi:10.5281/zenodo.3897993.