Early in the system design process, a design method must be chosen. This choice is usually dictated by what methods the designer has previously used, not by an open selection process. In this paper, we provide descriptions of some available design methods and examples of their use. In this project, we will develop benchmark problems that will be solved by a variety of design methods and will identify characteristics of problems that might make one system design method more or less appropriate. The top-level question we wish to answer is "for which type of problem is each method best?"If a system is to be built, then the system must ultimately be described as a collection of state machines. However, these state machines are often not created by the systems engineers. The systems engineers use some method to create a high-level abstraction of the desired system. Then they turn this abstraction over to the specialty engineers who actually reduce it to a collection of state machines. In this paper, we present solutions for a simple design problem by using the following 11 high-level system design methods: state transition diagrams, algorithmic state machine (ASM) notation, model-based system engineering, Graphical Description Language, RDD-100, structured analysis (using entity relationship diagrams, data-flow diagrams, and state transition diagrams with Ward-Mellor notation), functional decomposition, object-oriented analysis (OOA) with Shlaer-Mellor notation, OOA and object-oriented design (OOD) with Booch notation, an operational evaluation modeling-(OpEM)-directed graph, and IDEF0. Each method was used by an expert user of that method. The solutions presented make it obvious that the choice of a design method greatly effects the resulting system design. Index Terms-Architecture, design methodology, logic design, object-oriented methods. ).M. Alford is an independent consultant, Dean (M'97) received the M. A. degree in information system consulting from Brigham Young University, Provo, UT, in 1989 and the Ph.D. degree in management information systems from the University of Arizona, Tucson, in 1995. He is a Research Scientist at the Center for Management Information, University of Arizona. He provides consulting and research services on a number of topics, including electronic meeting systems (EMS), collaborative business process reengineering methods, and collaborative systems analysis and design methods. He has helped develop group-enabled activity and data modeling software to support technical and nontechnical users. He also developed structured meeting methods for use with these tools. The activity model software has since been made commercially available through Ventana Corporation, Tucson. His research interests include electronic meeting support of process and data modeling, business process reengineering, systems analysis and design, and group elicitation of information systems requirements.Jeremy Duke received the B.S. degree in systems (software) engineering in 1994 and the M.S. degree in systems engine...
In this article it is proven that two systems are I/O equivalent with respect to an initial state pair if and only if their minimizations are isomorphic images, which means that the minimizations are essentially the same systems with just a renaming of states, inputs, and outputs. The concept of homomorphic images is also defined: One system is a homomorphic image of the other if the one system is simpler than the other, but has essentially the same overall functionality. Two systems that are I/O equivalent with respect to an initial state pair are not necessarily homomorphic images. Hence, a system that implements the one may not implement the other. To assume otherwise can lead to disaster. It is the responsibility of systems engineers assigned to system functional analysis to consider the I/O requirement and the performance requirement (which may include reusability considerations) and to specify functional system designs for implementation. It is the responsibility of systems engineers assigned to system architecture to consider the technology requirement and the cost requirement and to specify buildable system designs to implement those exact functional system designs, not the requirements for I/O behavior. This paper shows that the equivalence of two systems cannot be proven by looking only at input and output behavior.
No abstract
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.