Explore chapters and articles related to this topic
From Cognitive Work Analysis to Software Engineering
Published in Neville A. Stanton, Paul M. Salmon, Guy H. Walker, Daniel P. Jenkins, Cognitive Work Analysis, 2017
The purpose of UML is to provide a shared means of communicating the formal specification of a ‘system’ to everyone involved in the design process (Booch 2005). The approach combines several views that are brought together (‘unified’) under a common umbrella and that allow designers to describe and model a system using formalised drawing tools. UML, developed from a collection of object-oriented software design approaches, is intended to function as an industry standard for software design. In this chapter, we show how CWA can be translated into a subset of the different views used by UML. These views are the following: Use case diagrams: to represent the interactions between the system and the users or other external systems; useful for mapping the functional requirements or user needs for the system.Class diagrams: ‘classes’ are used in object-oriented programming languages such as C++ or Java or C#, and define the relationships, attributes and operations of objects.Package diagrams: for grouping classes and interfaces.Sequence diagrams: used to specify the type and order of messages passed between objects during execution.State diagrams: used to describe system states and transitions to be triggered for state changes.
Microcontroller Software
Published in Syed R. Rizvi, Microcontroller Programming, 2016
Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers have the daunting task to develop a plan for a solution. This may include low-level component and algorithm implementation issues as well as the architectural view. After the design development comes the implementation. One important point to note here is that the sequence of the phases like design development, coding, verification through test procedures, etc. is taken from a typical waterfall lifecycle of software development. For a graphical representation of the stages in waterfall lifecycle model, refer to the Appendix.
Overview
Published in William E. Lewis, David Dobbs, Gunasekaran Veerapillai, Software Testing and Continuous Quality Improvement, 2017
William E. Lewis, David Dobbs, Gunasekaran Veerapillai
As defined in Section 1, “Software Quality in Perspective,” the three major components of quality assurance are software testing, quality control, and software configuration management. The purpose of software testing is to verify and validate the activities to ensure that the software design, code, and documentation meet all the requirements imposed on them. Software testing focuses on test planning, test design, test development, and test execution. Quality control is the process and methods used to monitor work and observe whether requirements are met. It focuses on structured walkthroughs and inspections to remove defects introduced during the software development life cycle.
A machine learning approach to software model refactoring
Published in International Journal of Computers and Applications, 2022
Brahmaleen Kaur Sidhu, Kawaljeet Singh, Neeraj Sharma
Software design is a stage of the development process, wherein various representations of the software are built to guide the code construction activity and the following stages of development. The work product of this activity is a pack of graphical models that provide details about software's architecture, data structures, interfaces and components. Daniels [7] defines three kinds of models based on their purposes: Conceptual models describe a situation of interest in the world, such as a business operation or factory process.Specification models define what a software system must do, the information it must hold, and the behavior it must exhibit.Implementation models describe how the software is implemented, considering all the constraints and limitations of the computing environment.Thus the software can be modeled at different levels of abstraction at different times, with separate concerns that apply at different levels. Models also form a mode of communication among stakeholders. The industry tends to use models for tasks like simulation, generating test cases and parts or all of the source code. Above all, models depict the software's internal architectural properties that determine the quality of the software. Poor internal design induces complexity in a product which is the root cause of poor quality.
Extending data-driven model of software with software change request service
Published in Enterprise Information Systems, 2018
Zeljko Stojanov, Dalibor Dobrilovic, Jelena Stojanov
The use of visual languages, such as Unified Modeling Language (UML), in software design allows efficient communication between participants in development and maintenance. Quantitative results of an empirical study with 20 subjects in an industrial setting, presented by Dzidek, Arisholm, and Briand (2008), revealed that UML has no significant effect on the time required for the implementation of modification activities, but it has a significant positive impact on the functional correctness of modifications. This becomes very important for the accurate identification of the elements of a software system to be modified.
The impact of applying product-modelling techniques in configurator projects
Published in International Journal of Production Research, 2019
Lars Hvam, Katrin Kristjansdottir, Sara Shafiee, Niels Henrik Mortensen, Zaza Nadja Lee Herbert-Hansen
The literature describes modelling techniques for constructing the phenomenon model (e.g. Hegge and Wortmann 1991; Ulrich 1995; Erens and Verhulst 1997; Eppinger and Ulrich 2000; Stone, Wood, and Crawford 2000; Gonzalez-Zugasti, Otto, and Baker 2000; Dahmus, Gonzalez-Zugasti, and Otto 2001; Du, Jiao, and Tseng 2001; Fixson 2005; Huang, Zhang, and Liang 2005; Harlou 2006). Modelling techniques for building the phenomenon model and information model also have been detailed (e.g. Chao and Chen 2001; Felfernig, Friedrich, and Jannach 2001; Hvam 2001; Magro and Torasso 2003; Hvam, Mortensen, and Riis 2008). UML has been proposed as a way to represent the information model in configurator projects (Felfernig, Friedrich, and Jannach 2000; Hvam 2001; Hvam, Mortensen, and Riis 2008). UML is a visual modelling language that is used for visualising, specifying, constructing and documenting artefacts in software design (Booch, Rumbaugh, and Jacobson 2005). This article focuses on three different representations of knowledge in configurator projects: (1) UML-based modelling techniques, in which the phenomenon model and information model are considered in a visual way, (2) non-UML-based modelling techniques, in which only the phenomenon model is considered (e.g. structured bills of materials) and (3) non-formal modelling techniques (e.g. making a list of features in Word or Excel without any formal structure or modelling directly in the configurator). The Centre for Product-Modelling (CPM) procedure is a modelling technique that represents both the phenomenon and the information model using UML notation. To represent the phenomenon model, product variant master (PVM) and class responsibility collaboration (CRC) cards are used, and to represent the information model, class diagrams and CRC cards are used (Hvam 2001; Hvam, Mortensen, and Riis 2008). To represent UML-based modelling techniques, the CPM procedure is used in this study, partly because it is based on UML – also used to make phenomenon models – and partly because the authors have access to companies using the CPM procedure, along with companies using other methods (non-UML-based and non-formal modelling techniques).