Software Architecture and Detailed Design Evaluation

Multiple Criteria Decision Making for the Structural Organization of Software Architecture

“…One of the most suitable metric for such measures is function point (FP) metric, which indirectly measures software and the cost of its development. The value of this metric reflects the functional complexity of the product [2,26,27,28].…”

“…One of the metrics which indirectly measure the software complexity is Function Points metric [2,26,28]. The input data for this metric are obtained using system requirements.…”

Multi-formalism in Different Levels of Abstraction for Requirements Engineering and Architectural Design of Real-Time Embedded Systems

“…The design, development, implementation and maintenance of RTES has always been considered difficult and challenging [16], [17], [8], [18], [19]. RTES must accomplish their functional requirements, also meet cost, quality, reliability and safety requirements [20]. In this sense, Software Engineering proposes a variety of activities, processes, methods and tools that assist in the analysis, description, development and maintenance of RTES [10], [13], [21].…”

“…Among the other software development activities, Architectural Design, mapped here in the Functional, Logical and Technical viewpoints, is defined as the set of activities that involves analyses, refinements and development of system requirements at different abstraction levels. The architectural design represents a fundamental activity during the development of the RTES [34], [35], [36], [20], [18]. Architectural design artefacts aims to describe software structure (detailing its components), to capture initial decisions of the project, to present the behavioral overview of the system, to specify system technical artifacts and, also, to contribute to the general reliability of the system [37], [29].…”

“…In a general sense, RTES engineers tend to use different approaches (formal, graphical models or object-oriented) for modelling, analysis and specification of RTES [50], [51], [47]. Furthermore, the specification language must be robust enough to represent the system requirements at different abstraction levels in order to avoid omissions in the specification and enable elicitation of physical, logical and temporal requirements, as well as other aspects that describe these systems [20]. Thus, adoption of approaches based on perspectives, multiple granularity levels and refinements, together with formal and semiformal languages, contributes to the system design, development of their components and complex relationships [52], [11], [44], [53], [54].…”