As the author being a student of a program in electrical sciences and information systems, at a certain online university, part of the author's attendance to the same university is represented by way of the author's own discussion forum responses. In those courses presenting of topics that the author may consider to be somehow relevant to the author's own informal academic studies, the author may wish write at length, to develop any single thesis in a response to the forum items. When time allows, then the result is -- typically -- something like a short, informal thesis paper -- often, towards a thesis in some ways orthogonal to the the content of the original discussion forum item, though addressing the discussion forum item to any single point of orthogonal relation.
This year marks what will have been the last year of the author attending that same institution -- the author planning on continuing from the simple associates program, into a broader study of mathematics. The author does not wish to denote the present institution, in any too short regards, if it may seem to invite any sense of competition from readers.
The following article, in is present edition, is a transcription of the author's own response to a discussion forum item. Though it would be perhaps overmuch, to develop a complete thesis article in that discussion forum, but perhaps this article may be revised at some later time, to be expanded into a full thesis document. The topic was, essentially: Modular design.
A modular approach to systems design may allow for a sort of functional definition of the functionality of reusable, individual systems elements and the interactions of individual systems elements in any constructed system. Perhaps it may be said to be a concept extending of some fundamental principles of object oriented software design -- such as of encapsulation and reusability. In some further abstraction, perhaps a concept of modularization may be said to extend of some concepts defined in broader mathematical set theory, such as with regards to sets defined of properties of sets -- in a sense, functional sets, though I'm afraid that my terminology as such might not be conventional within the broader mathematics.
Perhaps in a broad sense, the model driven architecture described by the Object Management Group (OMG)[1] may be considered to represent something of a development of a practical, normative medium for developing a modularized view of a complex system. Considering a feature developed of the model driven architecture, SysML -- technically, as SysML being defined from a metamodel implementing the Metaobject Framework (MOF), as also published by the OMG -- practically, SysML develops a number of generic concepts for developing a modular view of any discrete system[2] SysML is used specifically in some applications in the automotive industry[3].
Hypothetically, SysML may be applied for modeling of any discrete system -- even so simple a system as of a conventional household appliance, such as a simple toaster for bread. For a design of a system involving many of discrete components, however, a modeling language such as SysML may serve to develop a medium for definitions of the components of the system, in regards to component functionality, functional interactions between components, and applications of components within their intended usage environments.
Certainly, considering the complexity and nuances of definitions in SysML -- for instance, as with regards to types of elements that may be applied within any of the various types of model diagram in a SysML model, and applications of SysML models within any form of practice, and the extensibility of SysML as via UML prototypes -- SysML also inheriting some features of the Unified Modeling Language (UML) another metamodel extending of MOF -- perhaps SysML may seem to be overly complex for small applications in systems design.
Perhaps, orthogonal to a concept of modular design -- namely, in regards to vendor communications and systems conformance -- SysML serves to establish a common diagram language -- perhaps, as an alternative to ad hoc flowcharts in systems design. Semantically, SysML serves to establish a sort of common semantics for modular views of systems.
Hypothetically, even a single, functional VI -- such as would be defined, functionally, in LabView's G data flow language -- a VI could be modeled semantically, in a SysML block diagram. In a short estimation: a VI in LabVIEW may be modeled in SysML with a 'block' element, then defining a SysML 'port' element to the same block, for each input and output defined in the VI. Semantically, if a number of VI 'block' diagrams were defined, they could then be illustrated -- in any level of abstraction -- illustrated for those VI's interactions within a LabVIEW G program.
For a complex system of VIs and external devices communicating with LabVIEW as via a PXI interface[4], perhaps a SysML diagram could serve to provide something of a simplified view of the functionality of the system of VIs, devices, and other physical systems elements.
Hypothetically, if there may be any practical benefits assumed of a development of a SysML diagram for a system applying LabVIEW: Such a development might serve to assist in applications of the system, and in maintenance of its design -- thus highlighting a few more benefits of modular design, as ideally towards addressing concerns of interoperability and maintainability,as directly with regards to discrete system A, indirectly with regards to the original design of the system A.
Works Referenced:
[1] OMG. MDA Guide. PDF edition
[2] Friedenthal, Sanford et al. OMG Systems Modeling Language (OMG SysML™)Tutorial . PDF edition
[3] Weilkins, Tim. Systems Engineering with SysML/UML. Morgan Kauffmann OMG Press. 2007. Kindle edition
[4] National Instruments. PXI Platform. Web page.
This year marks what will have been the last year of the author attending that same institution -- the author planning on continuing from the simple associates program, into a broader study of mathematics. The author does not wish to denote the present institution, in any too short regards, if it may seem to invite any sense of competition from readers.
The following article, in is present edition, is a transcription of the author's own response to a discussion forum item. Though it would be perhaps overmuch, to develop a complete thesis article in that discussion forum, but perhaps this article may be revised at some later time, to be expanded into a full thesis document. The topic was, essentially: Modular design.
A modular approach to systems design may allow for a sort of functional definition of the functionality of reusable, individual systems elements and the interactions of individual systems elements in any constructed system. Perhaps it may be said to be a concept extending of some fundamental principles of object oriented software design -- such as of encapsulation and reusability. In some further abstraction, perhaps a concept of modularization may be said to extend of some concepts defined in broader mathematical set theory, such as with regards to sets defined of properties of sets -- in a sense, functional sets, though I'm afraid that my terminology as such might not be conventional within the broader mathematics.
Perhaps in a broad sense, the model driven architecture described by the Object Management Group (OMG)[1] may be considered to represent something of a development of a practical, normative medium for developing a modularized view of a complex system. Considering a feature developed of the model driven architecture, SysML -- technically, as SysML being defined from a metamodel implementing the Metaobject Framework (MOF), as also published by the OMG -- practically, SysML develops a number of generic concepts for developing a modular view of any discrete system[2] SysML is used specifically in some applications in the automotive industry[3].
Hypothetically, SysML may be applied for modeling of any discrete system -- even so simple a system as of a conventional household appliance, such as a simple toaster for bread. For a design of a system involving many of discrete components, however, a modeling language such as SysML may serve to develop a medium for definitions of the components of the system, in regards to component functionality, functional interactions between components, and applications of components within their intended usage environments.
Certainly, considering the complexity and nuances of definitions in SysML -- for instance, as with regards to types of elements that may be applied within any of the various types of model diagram in a SysML model, and applications of SysML models within any form of practice, and the extensibility of SysML as via UML prototypes -- SysML also inheriting some features of the Unified Modeling Language (UML) another metamodel extending of MOF -- perhaps SysML may seem to be overly complex for small applications in systems design.
Perhaps, orthogonal to a concept of modular design -- namely, in regards to vendor communications and systems conformance -- SysML serves to establish a common diagram language -- perhaps, as an alternative to ad hoc flowcharts in systems design. Semantically, SysML serves to establish a sort of common semantics for modular views of systems.
Hypothetically, even a single, functional VI -- such as would be defined, functionally, in LabView's G data flow language -- a VI could be modeled semantically, in a SysML block diagram. In a short estimation: a VI in LabVIEW may be modeled in SysML with a 'block' element, then defining a SysML 'port' element to the same block, for each input and output defined in the VI. Semantically, if a number of VI 'block' diagrams were defined, they could then be illustrated -- in any level of abstraction -- illustrated for those VI's interactions within a LabVIEW G program.
For a complex system of VIs and external devices communicating with LabVIEW as via a PXI interface[4], perhaps a SysML diagram could serve to provide something of a simplified view of the functionality of the system of VIs, devices, and other physical systems elements.
Hypothetically, if there may be any practical benefits assumed of a development of a SysML diagram for a system applying LabVIEW: Such a development might serve to assist in applications of the system, and in maintenance of its design -- thus highlighting a few more benefits of modular design, as ideally towards addressing concerns of interoperability and maintainability,as directly with regards to discrete system A, indirectly with regards to the original design of the system A.
Works Referenced:
[1] OMG. MDA Guide. PDF edition
[2] Friedenthal, Sanford et al. OMG Systems Modeling Language (OMG SysML™)Tutorial . PDF edition
[3] Weilkins, Tim. Systems Engineering with SysML/UML. Morgan Kauffmann OMG Press. 2007. Kindle edition
[4] National Instruments. PXI Platform. Web page.
---
End Note: This article corresponds, indirectly, to the author's own informal studies -- broadly, with regards to data flow programming language design, more specifically towards a design of a graphical data flow semantics for Common Lisp, such that the author is endeavoring to develop in the design of a project named eSym. Of course, if copyright pirates begin to circle, it could be easily enough renamed to something more appropriate.
Insomuch as of that study, the author observes -- albeit, broadly -- that there is some of a crossover towards concepts perhaps represented in designs of Common Lisp compilers. There are, of course, also some more challenging features to the matter -- such as for how to define a block-level view of a function returning a variadic set of return values.* In an interactive diagram, that could be easily enough resolved, but what of in a static diagram, such as for an item of documentation? Perhaps that can be easily resolved, too -- one could define an "&REST" return-value port as in extending SysML's port type firstly with a concept of a "return value", supplemental to an extension of the SysML block type with a concept, "function" and as such, specifically for how such a concept is developed in Common Lisp.
Then there's the question: How to determine what values a function returns, and determine that in a portable manner? If nothing else -- towards an interface for such reflection in Common Lisp -- perhaps it may be developed in an implementation-specific manner, firstly, focusing on how function objects are implemented in any single open-source Common Lisp platform, then the design of it gradually revised for portability onto other Common Lisp platforms. In a real sense: This would not be so simple, if at all possible, without free/open source software licensing.
Sure, too: Perhaps most programming languages don't allow for returning multiple return values, as Common Lisp allows for -- as in a manner essentially orthogonal to the syntax of the list, insofar as functional return values, but also allowing for transformation of return values into a list of return values, if need be -- as may need not always be, considering the availability of the Common Lisp 'multiple-value-bind' macro, but certainly there are applications for a transformation of a multiple return value set into a formal list of return values -- albeit, that requiring some operations on CONS type objects, i.e."Consing".
* Semantically, the term variadic might be more often applied in regards to functional parameters, and not return values. In Common Lisp, the term variadic may also be applied to functional return values -- though perhaps it would not be an instantaneously accepted application of that term, as such.
Semantics - there are books about that, certainly.
