arXiv subjects

Aydin Homay

Publications and source records attributed to Aydin Homay.

4 recordsLinked to original sources

arXiv2026

A Deep Dive into Axiomatic Design -- Part I: Problem Formulation

Problem formulation translating customer needs and constraints into a minimum set of independent first-level functional requirements, is arguably the most critical step in every design framework, including axiomatic design yet it is frequently misunderstood or underestimated in practice. This paper focuses exclusively on problem formulation in axiomatic design it clarifies what first-level FRs are (and are not), explains why they should not legitimately vary across designers given the same needs and constraints, and highlights intrinsic difficulties and recurring pitfalls that lead to design failure. The discussion is grounded primarily in Nam P.Suh's three books. The Principles of Design, Axiomatic Design Advances and Applications, and Complexity Theory, and it offers practical guidance to help designers formulate well-posed first-level FRs. Finally, the paper briefly revisits problem formulation in the era of large language models and discusses what such tools can (and cannot) contribute at the first level.

cs.AI↗

arXiv2025

How to Define Design in Industrial Control and Automation Software

Design is a fundamental aspect of engineering, enabling the creation of products, systems, and organizations to meet societal and/or business needs. However, the absence of a scientific foundation in design often results in subjective decision-making, reducing both efficiency and innovation. This challenge is particularly evident in the software industry and, by extension, in the domain of industrial control and automation systems (iCAS). In this study, first we review the existing design definitions within the software industry, challenge prevailing misconceptions about design, review design definition in the field of design theory and address key questions such as: When does design begin? How can design be defined scientifically? What constitutes good design? and the difference between design and design language by relying on advancements in the field of design theory. We also evaluate the distinction between ad-hoc and systematic design approaches, and present arguments on how to balance complementary operational concerns while resolving conflicting evolutionary concerns.

cs.SE↗

arXiv2025

The Mythical Good Software

Good software has high cohesion and low coupling is clumsy, obscure, and in some certain cases could be actually a harmful state of being. It is clumsy because there is no perfect correlation between higher cohesiveness and optimum design, and it is obscure because it conveys the message that coupling and cohesion are two distinct design principles, while there are in principle the same design approaches, and only the time and space differ between them, and it could also be a harmful state of being because we should not always aim for higher cohesiveness without considering its cost. In the course of this study, we aim to elucidate for the readers the meaning and underlying philosophy of the aforementioned paragraph.

cs.SE↗

arXiv2025

Complexity and Coupling: A Functional Domain Approach

This paper provides a precise and scientific definition of complexity and coupling, grounded in the functional domain, particularly within industrial control and automation systems (iCAS). We highlight the widespread ambiguity in defining complexity and coupling, emphasizing that many existing definitions rooted in physical attributes lead to confusion and inconsistencies. Furthermore, we re-exhibit why coupled design inherently increases complexity and how potentially this complexity could be reduced. Drawing on examples from various disciplines, such as software engineering, industrial automation, and mechanical design, we demonstrate that complexity does not necessarily correlate with system size or the number of components, and coupling, unlike common belief in software engineering, actually does not occur in the physical domain but in the functional domain. We conclude that effective design necessitates addressing coupling and complexity within the functional domain.

cs.SE↗