Software Design PDF

Axiomatic design is applied with state transition representation to software design for Programmable Logic Controllers (PLC). By comparing several approaches of applying the principles of axiomatic design in order to generate an equivalent description in state transition representation, we conclude that hierarchical statecharts are an important description of the decomposition and zigzagging procedure at conceptual design stage. This notation helps to identify the goal states and other important design parameters, such as time delays, input signals from sensors, and shared memory data. Since statecharts may provide inherent uncoupled designs we introduce a modified design table for state transition description. The state transition table combines the state transition model with the matrix notation and maps the input conditions to output actions for each state. The table can then easily be employed for implementing the PLC program code. This is particularly important in large-scale PLC controlled systems where a substantial number of control engineers have to collaborate by exchangin the input/output specification among the partial systems. An example is prepared to illustrate the proposed design method.

Several formal software design methodologies have evolved in the past few years to guide and document the development of object-oriented software. OMT (Object Modeling Technique) and UML (Universal Modeling Language) are two of the most widely used notations for graphically documenting the design of software objects. While these methodologies can convey significant software design detail, they do not provide a mechanism for documenting the functional requirements that drive the software development process. In addition, object-oriented design does not maintain traceability between functional requirements and the design of software objects.

This paper presents a new software design methodology based on axiomatic design theory that incorporates object oriented programming. This methodology overcomes the shortcomings of various software design strategies – extensive software development and debugging times and the need for extensive maintenance – since it is not heuristic and provides basic principles for good software systems. A simple software program is presented here as a case study following the methodology. This case study shows the systematic nature of axiomatic design that has been generalized and can be applied to all different designs. The axiomatic design framework for software overcomes many of the shortcomings of current software design techniques: high maintenance costs, limited reusability, the need for extensive debugging and testing, poor documentation, and limited extensibility of the software, in addition to high development cost of software. The methodology presented in this paper has helped software engineers to improve productivity and reliability.

Software development projects require the translation of good abstract ideas into clear design specifications. Subsequent delivery of the software product in moderate-to-large scale projects requires effective project planning and assignments for a team of software engineers to meet deadlines in the presence of resource constraints. This paper explores the hypothesis that axiomatic design may be integrated into the process of project planning and task assignment for software development teams. An approach to mapping functional requirements and design parameters into tasks of a project plan Gantt chart is described. Effects of transferring the relationships of design matrices to task links are discussed. The result is considered by the authors to be a productive integration facilitating the rapid delivery of product by software engineering teams.

Software products are managed by several activities over their lifecycle. Requirements, Development, QA and Documentation are common categories describing these activities. Although the lifecycle is often referred to in linear terms, the reality is an iterative dynamic between lifecycle activities. A change in one activity can propagate indefinitely over the product lifecycle. One major reason for the frequent failure of software projects is the failure to deal with changes to requirements. Requirements seldom remain constant throughout the product lifecycle and must therefore be systematically managed to avoid introducing chaos into the design process. The axiomatic framework has been introduced to manage the design process in a systematic manner. It starts with requirements capture and continues the process by establishing linkages between domains (i.e. activities) over the design hierarchy. This requirements driven approach provides the insight to objectively gauge the impacts of changing requirements. The highly dynamic nature of software development provides an ideal demonstration of the framework’s capabilities.

The automatic design of engineering systems has been accomplished by the development of engineering optimization techniques. The methods find design solutions that minimize the cost function while given constraints are satisfied. The types of design variables are classified into continuous and discrete ones. Generally, available designs are discrete in design practice. However, optimization has been developed to determine designs in a continuous space. In recent research, a sequential algorithm using orthogonal arrays (SOA) has been proposed for design in a discrete space.

This paper contributes towards a rational foundation for User Interface Design (UID) methods. Currently UID process is primarily based on the trial-and-error approach, supported with miscellaneous testing techniques. In fact, we lack a scientific model for UID, explaining the objectives and concepts of UID and clarifying the solutions. There is an emergent need for a UID process to be not only broad enough to be applicable in different situations but also to be accurate enough to be applicable for specific cases. The current UID methods are based on an iterative process approaching the satisfactory solution in a successive chain of activities. In this paper, we strive to constitute the foundation of this challenging, rational design process. Usability may be defined as “quality of use” and it must be planned and engineered from a human perspective. Therefore, we need to systematically respect human needs, opinions, values, feelings, skills and limitations. Since the usability of a system stems from user, task, and context of use, we base our structure on the knowledge of these three elements. We construct our design model based on a pyramid of three elements: User-System- Context Needs, Concepts, and Principles. By means of AD theory, we linked these elements together to form the overall structure in which User-System-Context Needs, Concepts, and Principles play the roles of Customer Needs (CNs), Functional Requirements (FRs), and Design Parameters (DPs), respectively. The top level contains user-system-context needs, followed by Concepts (FRs) and Principles (DPs). Through AD approach, we seek the underlying concepts and principles in UID process. This model brings about both documenting design knowledge and facilitating communication. AD provide a good format for capturing background information and describing generically good solutions.

Software is playing an increasingly important role in manufacturing. Many manufacturing firms have problems with software development. Software engineering is still labor-intensive and prone to errors. Industrial firms are under pressure to shorten the lead-time required in introducing new software, increase the reliability of their software, and increase their market share. Software must be designed correctly from the beginning to end. With this end in mind, axiomatic design theory has been applied to software design. This paper presents how the combination of axiomatic design has been combined with the object-oriented programming method to create a large software system.

Proceedings of the 3rd International Conference on Engineering Design and Automation, Vancouver, B. C. Canada. August 1-4, 1999.
Today’s increasingly complex electromechanical systems require extensive use of software control to achieve necessary functionality. However, software design efforts for complex systems tend to be made only after most, if not all, of the hardware has been defined. As a result, the software often bears the burden of achieving the system’s desired functionality. While software is more flexible than hardware, the software design can often be greatly simplified with minor changes to the hardware design, if the software and hardware designs are done concurrently. Such unnecessary software complexity can have detrimental effects on the system in terms of safety and reliability under unusual operating conditions, as well as complicating upgrades and product redesigns. This paper proposes a methodology, based upon Axiomatic Design, for facilitating the design of software control systems in conjunction with their corresponding hardware systems. In the Axiomatic Design framework, a system is defined in a hierarchical structure known as a system architecture, where the specifications for the command and control logic, which is typically implemented in software, appear at each level of the design hierarchy. Thus, the design of the system software is distributed throughout the design of the system hardware. To apply this technique, programming terms are defined and their roles are explored in the Axiomatic Design framework. Next, a template is developed that represents system software and serves to highlight the functionality required to control and coordinate the various activities of the system hardware. A case-study example of a robot calibration routine is examined to illustrate these methods.

Integrated Design and Process Technology, IDPT-2006, June 2006.
Component Oriented Software Engineering (COSE) tools generally deal with the composition of components using their interfaces. They operate at the level of component’s interface and connect components by limited semantic guidance. These COSE approaches suffer from lack of standards and systematic documentation of component properties. A component interface is not detailed enough to define all interface items and relationships among them. However, Axiomatic Design matrix (AD) includes interface items and Functional Requirements (FRs). In this study, AD matrix notation is utilized for satisfying FRs defining interface items.