System Design | Development - Design Methodolody
Update #10115  |  06 Oct 2014

Model-Driven Development

In order to develop the project is implemented a Model-driven Development (MDD) process, “utilizing models to describe needed capabilities, and also to drive through the process and connect intent and implementation. This involves languages able to describe needs in linked and in disparate domains, a methodology that recognizes the separate needs, but the necessary connection points, and focused tools that serve key steps through this flow.”[1]

MDD aims to elevate functional models to a central role in the specification, design, integration, and validation of the system [2]. Model-Drive Development has been widely used in automotive and avionics industry where demonstrated its effectiveness for modeling [3] and [4].

IBM highlight several advantages of a system model creation [5]:

  • Provides integration of various views of a system into a cohesive unit.
  • Can be used to identify interfaces between “lower-level” systems
  • Can be used to specify collaborative behavior between “lower-level” systems
  • Can be executed to verify that system interactions meet requirements very early in the development process

This confirms how modeling will help to understand the system description and operation, from the early stage of conceptual design through implementation and evaluation.

The model driven methodology purpose and used for the project is described below:


Methodology Description

There are plenty of system design and development methodologies in the industry and academic field, in this chapter is presented a short and abstract description of the methodology adopted for the project development, following the main guidelines propose in [6] and [4].


1.      System Context Description

This is the starting point, where a clear definition of the system framework conditions and environment is placed. Describing all the relevant information from the system context, ideas and goals for the system. Followed by the stakeholder identification and their specifications for the system.

For this project, it was received a full set of system requirements from one of the main stakeholders, covering aspects of hardware, software, package and user interface that define the structure of the project. For this reason it is included this step between the context description and requirements engineering.


2.      Requirements Engineering

The requirements engineering has two phases [7],

  1.  Requirements definition, which consist on the identification, capture - collection, analysis and verification of the user requirements.[8] In order to extract the system requirements, assisted by the stakeholders requirements given at the beginning.
  2. Requirements management, control and facilitate the communication and collaboration between developer and stakeholders, throughout the organization. Enabling evaluation and tracking of requirements during the development process.

Requirements definition requires a direct interactions between user requirements and system requirements, where most like is perform recursions and iterations, bringing an outcome managed since the beginning to the end of the process.


3.      Use Cases Definition

Once the requirements are extracted and defined, they are grouped into use cases. A use case shows the typical interaction between the user and the system, describing operational aspects of the system and specifying the behavior as perceived by the users. A set of use cases is clustered in a use case diagram [9].

One of the main component of this stage are the actors, which specifies a role played by an entity that interacts with the subject. Actors can represent human users, a software or hardware component, or other subjects.      [10]


4.      System Modeling

‘’MDD use models to represent a system’s elements, the structural relationship between them, and their behavior and dynamic interactions.”[2]

This stage requires a functional and architectural analysis of the system, represented in different diagrams, in order to understand and manage interfaces between functionality and operation, evaluate design decisions, promote relevant questions and try out alternatives to solve it. Such a process in divided in two phases:

  • Modeling structure of the system, pointing the system’s elements relationship to support design exploration and system portioning.
  • Modeling behavior and interactions, essential step to verify designs by verifying models and for code generation.

There are no constraints to start with any of the two phases, due developing a system model is an iterative process, for this implementation it starts with behavioral modelling followed by the structure model.

“This models should be represented in a modeling language with a formally defined grammar and semantics capable of expressing both static structure and dynamic behavior at an abstract level removed from the programing domain” [2].


System Modeling Language

For this project the language selected is the Systems Modeling Language (SysML), developed by the Object Management Group (OMG), who defines it as [5]:

  • “A general-purpose modeling language for systems engineering applications. SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, information, processes, personnel, and facilities."
  • “SysML is a subset of UML with extensions needed to satisfy the needs of the Systems Engineering Community”.

SysML includes 3 main areas structure, behavior and others [10] [4]:




Structure Model

Visualize, specify, construct, and document static system aspects

Block definition diagram, internal block diagram, parametric diagram, package diagram

Behavioral Mode

Visualize, specify, construct, and document dynamic system aspects

Activity diagram, use case diagram,, state machine diagram, sequence diagram



Requirements diagram

 In the following two schemas are described SysML structure [4] and its diagrams description [11]:

SysML Structure

SysML structure

SysML Diagrams

 SysML diagrams

For the methodology implementation where selected the following diagrams per each phase:

System Modeling Phase

 Diagrams Selected

Modeling Behavior

  • Use Case Diagram
  • Sequence Diagram
  • State Diagram

Modeling Structure

  • Block Definition Diagram


Systems Modeling Tool

 The modeling tool selected is IBM® Rational® Rhapsody® Architect for Systems Engineers. “An integrated, systems engineering environment for analyzing project requirements. It uses Systems Modeling Language (SysML) and Unified Modeling Language (UML) to enable rapid requirements analysis and visual, model-based design.”[12]


5.      System Evaluation

In addition to functional requirements a system has non-functional requirements to fulfill (NFRs), sometimes called as a quality attributes [13], which describe how the system must operate. There are several NFRs to be considered in the system evaluation, for example some are included in the following definition:  “NFR is a requirement that specifies system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability. A requirement that specifies physical constraints on a functional requirement” [14]; some of their classifications can be found on [14] and [15].  However in this project, the system evaluation is focused in reliability and performance, which are two of the keys quality attributes more relevant in the system design [13].



Quality attribute that refers to the continuity of correct service [16]. A well know definition, “reliability is the ability of an item to perform a required function under stated conditions for a stated period
of time” [17]. Based on the fact that a system will not deliver its function if there are component failures, a certain sequence of component failure will define system reliability. Therefore it will make necessary to quantify and model system reliability, for this purpose a good reliability definition is “ the probability that the system will perform satisfactorily from time zero to time t, given that operation commences successfully at time zero (the probability that the system will conform to its specification throughout a period of duration t)”[18]

The system reliability evaluation is perform by modeling, where each model focuses on a particular level of abstraction and/or system characteristics [13]. There are two types of models [19]:



Component – based models


  • Reliability block diagram
  • Fault tree

State – based models

  • Markov chains
  • Petri nets

For this project is selected a fault tree model, component based.


Fault tree

An application of deductive logic to produce a fault-oriented pictorial diagram which allows one to analyze system safety and reliability [19]. Where:

  • A complex event such as a system failure is consecutively broken down into simpler events such as subsystem failures, individual components and block failures, down to single element failures. These simple events are linked together by "and" or "or" Boolean functions [19].
  • System reliability is obtained by quantifying the probability of occurrence of the fault-tree’s top-event. The probability of higher level events can be calculated by combining probabilities of the lower level events.[19][20]



Several metrics provide quantitative assessment on reliability, such as mean time to failure (MTTF), mean time to repair (MTTR), probability of continuous correct operation and failure rate.


  •  “Mean-Time-To-Failure (MTTF) is the average time between a renewal (completed repair) and the next following failure”. [18]
  • “Mean-Time-To-Repair (MTTR) is the mean of the repair time of a system”. [18]



Performance is a general quality attribute which involves various system aspects like responsiveness, throughput and resource usage. A performance property can be defined as a metric of a system that shows how fast a system executes a certain functionality [13]. Is important to highlight that sometimes reliability is classify as a performance requirement.

In order to guideline the performance evaluation of the system, the following metrics are selected:




The difference between the estimated and actual value of[21]:

-          The hot air balloon position.

-          Temperature.


The capability of the system to perform its function without unscheduled interruptions during the intended operation.[22]


How well the system utilize a resource. In terms of capacity (how fast does it process), throughput and response time of the system.[21]


Nevertheless, it leaves open the possibility to take into account more metric and/or NFRs to evaluate the system.

For the proposed methodology modeling reliability will provide the system reliability evaluation, which afterwards will be analyzed together with other performance evaluation metrics.





[1] Bill Chown and Michelle Lange. Modernizing system development: requirements-based, model-driven design, implementation, and test. White paper system level engineering. Mentor graphics, 2012

[2] Mike Kleidermacher and David Kleidermacher. Embedded Systems Security. Practical Methods for Safe and Secure Software and Systems Development, Chapter 3. Newnes, 2012

[3] D. Milicev. Model-Driven Development with Executable UML. Wiley Publishing, 2009.

[4] T. Weilkiens. Systems Engineering with SysML/UML: Modeling, Analysis, Design. Morgan Kaufmann OMG Press, 2007.

[5] IBM presentation. Model Driven Development with SysML. INCOSE, 2009

[6] Igor Kaitovic, Slobodan Lukovic. Adoption of Model-Driven methodology to aggregations design in Smart Grid. ALaRI, USI Lugano.

[7] IBM Product development, white Paper, requirements engineering. June 2009

[8] E. Hull, K. Jackson, and J. Dick. Requirements Engineering. Springer, 2011.

[9] IBM White paper, SysML-based systems engineering using a model-driven development approach, 2008.

[10] Igor Kaitovic and Mauro Prevostini, UML-SysML for SoC Design, ALaRI USI Lugano, 2012

[11] Sanford Friedenthal Joseph Wolfrom, Modeling with SysML. APL John Hopkins University.

[12] IBM product description, http://www-03.ibm.com/software/products/en/ratirhaparchforsystengi

[13] Indika Meedeniya, Architecture Optimisation of Embedded Systems under Uncertainty in Probabilistic Reliability Evaluation Model Parameters, Swinburne University of Technology. 2012

[14] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Reading, Mass.: Addison Wesley. 1999

[15] Cleland-Huang, J.  Settimi R. Xuchang Zou. Solc, P. The Detection and Classification of Non-Functional Requirements with Application to Early Aspects. 2006

[16] Lawrence Chung, University of Texas at Dallas. Non Funtional Requirements, practices and recommendations.

[17] IEEE Standard Dictionary of Electrical and Electronics Terms, IEEE Std. 100-1996, 1996

[18] Prof. Dr. Miroslaw Malek. Dependable systems – Concepts and measures. ALaRI- USI Lugano.2014

[19] Prof. Dr. Miroslaw Malek. Dependable systems – Dependability modeling and tools. ALaRI- USI Lugano.2014.

[20] Dominguez-Garcia A. An Integrated Methodology for the Performance and Reliability Evaluation of Fault-Tolerant Systems. MIT. 2007

[21] Jim Nagle. ICAO policy on GNSS, GNSS SARPs and global GNSS developments. ICAO.

[22] Mylopulos, J. Chung, L. Nixon, B. Representing and Using Nonfuntional requirements: A process-oriented approach. IEEE transactions on software engineering Vol 18. No 6. 1992

 More info www.globodaq.co


gmail       pinterest   twitter   wordpress