The Modularity Matrix as a Source of Software Conceptual Integrity
Iaakov Exman
Software Engineering Dept., The Jerusalem College of Engineering JCE - Azrieli, POB 3566, Jerusalem, Israel
Keywords: Conceptual Integrity, Modularity Matrix, Conceptual Lattice, Linear Software Models, Liskov Substitution
Principle, Abstract Mathematical Concepts, Standard Modularity Matrix, Software System Design.
Abstract: Conceptual Integrity has been declared the most important consideration for software system design.
However, the very concept of Conceptual Integrity remained quite vague, lacking a precise formal
definition. This paper offers a path to a novel definition of Conceptual Integrity in terms of the Modularity
Matrix, the basic structure of Linear Software Models. We provide arguments for the plausibility of the
Modularity Matrix as the suggested source of software system Conceptual Integrity, viz. the orthogonality
and propriety of the Matrix modules. Furthermore, the paper also reveals some new characteristic properties
of Software Conceptual Integrity.
1 INTRODUCTION
We can trace back the idea of conceptual integrity,
in the context of software, to Brooks in his well-
known book “The Mythical Man-Month” in
Chapter 4, page 42 of the anniversary edition
(Brooks, 1995). Already there, it is said that
conceptual integrity is the most important idea for
software system design. The idea has been proposed
and praised, but not exactly defined.
This paper offers a path to a formal definition of
conceptual integrity in terms of the Modularity
Matrix. This matrix is the basic algebraic structure
of Linear Software Models.
In this Introduction section we clarify the idea of
software conceptual integrity, as far as it has been
done since its initial presentation by Brooks, and
concisely review the basics of the Modularity
Matrix.
1.1 Software Conceptual Integrity
The idea of conceptual integrity, in the context of
software, has been reiterated in a more recent book
by Brooks The Design of Design: Essays of a
computer scientist in Chapter 6, pages 69-70
(Brooks, 2010).
There, conceptual integrity is said to consist of
three principles referring to system functions. These
principles have been verbally formulated in a paper
by De Rosso and Jackson (De Rosso and Jackson,
2013) as follows:
Orthogonality individual functions
should be independent of one another;
Propriety the system should have only the
functions essential to its purpose and no
more;
Generality a single function should be
usable in many ways.
There are a few problems with these formula-
tions, but the most important one is that there is no
“algorithm” or “protocol” to make concrete usage of
these principles.
This work has as its aim to offer a formal path to
conceptual integrity, gaining in this process both a
deeper understanding of this idea and the basis for a
practical application of the above principles. Thus,
among other things, if the above principles are
indeed the essence behind conceptual integrity, then
they must follow as consequences of the offered
formal path.
1.2 Modularity Matrix
The Modularity Matrix see e.g. (Exman, 2014) is a
representation of a hierarchical software system in
its several abstraction levels, through sub-systems,
down to indivisible basic modules. The matrix
columns, the structors, stand for architectural
structure units, generalizing classes. The matrix
Exman, I.
The Modularity Matrix as a Source of Software Conceptual Integrity.
DOI: 10.5220/0006098300270035
In Proceedings of the 7th International Workshop on Software Knowledge (SKY 2016), pages 27-35
ISBN: 978-989-758-202-8
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
27
rows, the functionals, stand for architectural
behavioural units, generalizing class methods.
Algebraic manipulations lead in the optimal case
to a standard square and block diagonal matrix, in
which the blocks along the diagonal are the modules
of the current matrix level. This is seen in the
abstract Modularity Matrix displayed in Fig. 1.
Figure 1: An Abstract Standard Modularity Matrix The
matrix is standard as it is strictly square and block-
diagonal. It has 6 structors (columns) and 6 functionals
(rows). Its 3 modules are the three blocks in the diagonal,
having 1 valued matrix elements (with light blue
background). Outside the modules (blank areas) there are
only zero-valued matrix elements. These values are
omitted for simplicity.
In case there remain some non-zero outlier
matrix elements, i.e. outside the diagonal modules,
these elements point out to undesirable couplings
among the modules. These couplings should be
resolved by moving structors/functionals among
modules or by adding/removing structors and/or
functionals, in the columns/rows containing the
outliers.
1.3 Related Work
In this concise review of the related literature we
mention works referring to Conceptual Integrity.
We also mention tools which support this notion,
particular discussions of orthogonality in this
context and different kinds of matrices used to
analyse software design, besides the Modularity
Matrix.
The origin of Conceptual Integrity ideas, as
already mentioned in the beginning of this
Introduction, is Brooks’ book originally published in
1975, with an extended edition 20 years later
(Brooks, 1995).
Jackson and co-workers have further elaborated
on the Brooks’ notions, say by means of cases
studies, see e.g. (De Rosso and Jackson, 2013).
Jackson also formulated a relevant Research Agenda
(Jackson, 2013). In a recent essay Jackson stresses
the importance of concepts for software systems,
and gives examples of arrangements of concepts in a
dependence graph, from which coherent subsets can
be extracted and analysed. But, these graphs have
not been formalized (Jackson, 2015).
Documents that explicitly refer to Conceptual
Integrity occasionally mention it, and often
formulate some vague statement about what this
means, see e.g. Beynon et al. in (Beynon, 2008).
Kazman and Carriere in page 31 of a Technical
Report (Kazman, 1997) describe the problem of
reconstructing the software architecture of a system.
Their guide to a good and meaningful architecture is
conceptual integrity. It should be built from a small
number of components connected in regular ways,
with consistent allocation of functionality to the
architecture’s components.
Clements et al. in their book (Clements, 2001)
refer to conceptual integrity as the underlying theme
that unifies the design of the system at all levels. The
architecture should do similar things in similar ways,
having a small number of data and control
mechanisms, and patterns throughout the system.
There are two points to be stressed in this statement:
a- they refer to the system at all levels; b- a possible
approach to a more precise definition would be
counting mechanisms and patterns.
The concept of orthogonality also appears
occasionally in the software development literature.
For instance, Krone and Snelting refer to it in a
paper using conceptual lattices inferred from source
code (Krone, 1994).
Another kind of works refers to software tools to
support software systems analysis and design. For
instance, (Kazman, 1996) describes a so-called
SAAMtool, with visualization capability.
Conceptual Integrity is estimated by the number of
primitive patterns that a system uses.
Finally, there are papers dealing with other
matrices, besides the Modularity Matrix, for
software systems design. The DSM (Design
Structure Matrix) is part of the Design Rules
approach (Baldwin and Clark, 2000) and adopted by
many works, appeared and has been applied outside
the software engineering context. For a set of
references to this approach see e.g. (Exman, 2014).
SKY 2016 - 7th International Workshop on Software Knowledge
28
1.4 Paper Organization
The remaining of the paper describes a formal path
to conceptual integrity (section 2); shows how
conceptual integrity principles follow from the
Modularity Matrix (section 3); characterize
properties of conceptual integrity (section 4); and
conclude with a discussion (section 5).
2 FORMAL PATH TO SOFTWARE
CONCEPTUAL INTEGRITY
We propose a formal path from an Abstract Domain
Conceptualization to Software Conceptual Integrity.
We claim that Conceptual Integrity exists, say in
abstract mathematics, before being formally defined.
We first overview the formal path, leading
through the Modularity Matrix to the main goal of
Software Conceptual Integrity. We then look in
more detail at each of the steps made in this path.
2.1 Overview of the Formal Path
A formal path from Abstract Conceptual Integrity to
Software Conceptual Integrity, passing through the
Modularity Matrix has 5 states with 3 intermediate
states in between. These are shown in Fig. 2.
Figure 2: From An Abstract Domain To Software
Conceptual Integrity The five states are: the initial state
“Abstract Mathematics”; the goal state “Software
Conceptual Integrity”, and three intermediate states: a-
Liskov Substitution; b- Modularity Matrix; c- Conceptual
Modularity Lattice.
The meaning of the five states in the formal path
is as follows:
1. Abstract Mathematics Conceptualization
due to its long history, concepts in
Mathematics were classified in fields and
sub-fields, within hierarchies obeying
conceptual integrity;
2. Liskov Substitution it is an attempt to
translate abstract mathematics notions to
equivalent software notions; the central
idea here is to link “structure” to
“behavior”;
3. Modularity Matrix the basic algebraic
structure of Linear Software Models, used
to guide software system design; it restricts
whole domains to a modularized class of
software systems;
4. Conceptual Modularity Lattice this is a
particular case of conceptual lattices
(defined in FCA = Formal Concept
Analysis) derived from the Modularity
Matrix; it obtains the concepts of the
software system modules;
5. Software Conceptual Integrity the
desired goal of the whole path, will assure
software system orthogonality and
propriety.
One can summarize the above states by their
roles, as shown in Fig. 3.
Figure 3: FORMAL PATH: TOOLS, GOALS, And
ROLES This summarizes the properties of the Formal
Path states in terms of their formal tools, goals and roles.
See detailed discussion in subsequent subsections. LSP
means Liskov Substitution Principle.
2.2 Preliminary Definitions
Here we provide some preliminary definitions
needed to discuss in detail each of the above states.
Despite starting with an abstract mathematics
domain, the ultimate goal of the formal path refers to
software systems. Therefore, when talking about
The Modularity Matrix as a Source of Software Conceptual Integrity
29
structure and behavior we think in terms of software.
Here are the relevant definitions.
Definition 1 Software Structure
Software Structure is a relation among software
architectural units (classes and their
generalization “structors”) involving the
following operators: sub-classing (sometimes
called “inheritance”) and composition.
It is not by chance that we are using the same
operators for software systems and for abstract
ontologies. We are just following common practice,
which emphasizes the analogies between abstract
concepts and their respective software classes.
Definition 2 Software Behavior
Software Behavior is the performance of the
computation of a function (sometimes called a
method). The result of the function computation
is a change of state of a software system. We call
functions (and their generalization “functionals”)
software architectural units of behavior.
Functionals are provided by structors, but are not
necessarily invoked. Thus we often, by linguistic
license, refer to the functions themselves without
the performance of a computation as software
behavior.
2.3 Conceptual Integrity in Abstract
Mathematics
Mathematical concepts are classified by properties’
similarity in a hierarchical fashion. The hierarchy is
determined by which concepts are particular cases of
other ones. We clarify the idea with some examples.
A square is a subclass (particular case) of a
rectangle, which is a subclass of a parallelogram,
which in turn is a subclass of a quadrilateral. A
quadrilateral, the most general case in this small
hierarchy (in Fig. 4), is a polygon with four sides. A
parallelogram is a subclass of quadrilateral with
opposite sides parallel. A rectangle is a subclass of a
parallelogram with four right angles. A square is a
subclass of a rectangle with all four sides equal.
Each lower hierarchy class has all the properties
of the upper classes. A square has 4 sides (as the
quadrilateral), which are parallel (as in the
parallelogram), and 4 right angles (as the rectangle).
This is also true with respect of behavior, i.e. the
outcome of what the respective functions calculate
for each concept (or each class). For instance, the
perimeter of any of the classes in this hierarchy is
calculated in general by summing the length of the
four sides (which may be all different, partially
Figure 4: The Quadrilaterals Hierarchy Each arrow
(meaning subclass or subtype of) points from the
particular class to the more general class. Quadrilateral is
the most general class of this hierarchy and Square is the
most specific class.
different or all equal).
A different hierarchy would have a circle as a
subclass of an ellipse. A third different hierarchy
would deal with 3-dimensional objects such as a
sphere as a subclass of an ellipsoid.
Each of the three referred hierarchies
(quadrilaterals, ellipses, 3-D ellipsoids) display
conceptual integrity, both intuitively and by some
specific well-defined characteristic. For example, all
quadrilaterals in Fig. 4 have linear segments as sides
of a polygon (literally meaning "multiple angles"),
while the ellipses have no linear segments and no
angles in between at all in their perimeters.
These hierarchies, such as that the quadrilaterals
in Fig. 4, are in fact small fragments of an ontology
of geometric figures, e.g. (Rovetto, 2011), which
may encompass the three referred hierarchies.
We summarize conceptual integrity in an abstract
domain such as mathematics by means of the
following theorem:
Theorem 1 Conceptual Integrity in Abstract
Domain Hierarchy of Concepts
In a class hierarchy determined by sub-classing, in
an abstract domain, all the concepts of the
hierarchy have at least one common concept,
and one common function defined in the
most general member of the hierarchy. The
common concept and the common function
stand for the conceptual integrity.
SKY 2016 - 7th International Workshop on Software Knowledge
30
2.4 Liskov Substitution
The Liskov Substitution Principle (LSP) attempts to
translate, as precisely as possible, notions found in
Abstract Mathematics, as discussed above (in
subsection 2.3), to the realm of software. This is
possible since the ontology fragments (hierarchies)
in abstract mathematics are built upon the
subclassing operator, while it can be said that LSP is
an effort to define “inheritance” which is the
software term for subclassing.
The basic idea of Liskov Substitution which is
relevant to conceptual integrity is to link “structure”
to “behavior”, effectively transforming concepts in
an abstract (e.g. “mathematics”) domain into generic
software.
A formulation of the Liskov Substitution
Principle (Liskov, 1988) is shown in Fig. 5. A
corresponding class diagram illustrates it in Fig. 6.
The main principle conditions are marked in
bold: a- 'all programs P' assures that the principle
still is generic in terms of software, i.e refers neither
to a specific software system nor to a specific class
of software systems, but is not clear how to test it in
real systems; b- 'behavior of P is unchanged' is
particularly interesting, as a structural class
diagram (type T and its subtype S) is being linked to
a behavioural condition, which is precisely what
transforms an abstract domain to software concepts!
We summarize conceptual integrity within
Software according to the Liskov Substitution
Principle by the following theorem.
Theorem 2 Conceptual Integrity in Liskov
Substitution
If by the Liskov Substitution Principle, a sub-class
object substitution by a parent class object,
causes no change of behavior of a system,
Conceptual Integrity is preserved, when one
passes from an abstract domain to a whole
domain of software systems.
Figure 5: Liskov Substitution Principle Formulation The
significant terms of the principle are stressed in bold face:
“all programs P” for generality; “behavior is unchanged”
linking structure to behavior.
Figure 6: Liskov Substitution Principle Class Diagram
This is a class diagram illustrating Liskov's principle. T is
a class (or type). S is subclass (or subtype) of T. Object o1
is of type S, and object o2 is of type T. This diagram is
analogous to an abstract hierarchy in Fig.4. The arrow-
head is white to conform to the UML convention.
2.5 Modularity Matrix
The Modularity Matrix of a software system is built
using structors (a class generalization) preserving
the notion of sub-classing. Thus, the Modularity
Matrix implicitly conveys the central ideas for which
the Liskov Substitution Principle was formulated.
The important contribution of the Modularity
Matrix, from the viewpoint of the argumentation
along the current Formal Path is to restrict the
complete generality of Liskov Substitution i.e. for
all programs P, translated to for all software systems
P into a limited set of software systems defined by
the Modularity Matrix structors and functionals.
This is summarized by the following theorem:
Theorem 3 Conceptual Integrity in the
Modularity Matrix
If the Modularity Matrix is standard (square and
block-diagonal), then specific structors
provide related functionals within modules,
and the modules conceptual integrity is
preserved for the restricted set of software
systems represented by the Matrix.
2.6 Conceptual Modularity Lattice
The Conceptual Modularity Lattice the last link
towards Conceptual Integrity has been shown
(Exman and Speicher, 2015) to be equivalent to the
Modularity Matrix, in terms of information
conveyed about its software system modularity.
On the other hand, by its very definition - from
FCA (Ganter and Wille, 1998) the Conceptual
Modularity Lattice is an algebraic structure
restricted to the concepts relevant to its software
system.
Summarizing, the role of the Conceptual
Modularity Lattice in our formal path, is by its
The Modularity Matrix as a Source of Software Conceptual Integrity
31
equivalence to the Modularity Matrix, and the
conceptual relevance, to enable to extract from the
Modularity Matrix the module concepts which may
be tested for Conceptual Integrity.
This is shown by the following theorem.
Theorem 4 Conceptual Integrity in the
Modularity Lattice
Since the Modularity Lattice is software design
equivalent to its corresponding Modularity
Matrix, the concepts fitting to the Matrix
modules preserve conceptual integrity and
this can be explicitly tested for the restricted
set of software systems represented by the
Modularity Lattice.
3 CONCEPTUAL INTEGRITY
PRINCIPLES FROM THE
MODULARITY MATRIX
In this section we finally assign a formal definition
to two of the principles referred to in sub-section
1.1 behind Conceptual Integrity, viz. Orthogona-
lity and Propriety. The proposed definitions are
based on the Modularity Matrix properties.
3.1 Orthogonality
Orthogonality, as already stated (DeRosso and
Jackson, 2013) in section 1.1 is "individual functions
should be independent of one another". Based upon
the Modularity Matrix, this definition has two
associated meanings:
Linear independence among structors and
among functionals;
Strict orthogonality among modules, which
is also a consequence of linear independence,
is easily visually recognized in the diagonal
blocks of the Modularity Matrix.
So, orthogonality, from the Modularity Matrix, is
totally consistent with the earlier intuitive
formulation.
3.2 Propriety
Propriety reflects the fact that the Modularity Matrix
is the result of optimization of the number of linear
independent structors and their provided functionals.
In other words, linear independence of structors (and
linear independence of the corresponding function-
nals), means that there are no superfluous structors,
just the strictly necessary minimal number.
This is also consistent with the earlier intuitive
formulation, viz. "a system should only have the
functions essential to its purpose and no more".
See the Discussion sub-section 5.2 for
considerations on “Generality”.
4 CONCEPTUAL INTEGRITY
CHARACTERISTICS
In this section we go beyond the definitions based
upon the Modularity Matrix, suggesting additional
conceptual integrity characteristics that could
sharpen the understanding the nature of conceptual
integrity.
4.1 Conceptual Integrity Is Intensive
Here we suggest that conceptual integrity, besides a
property of a whole hierarchical software system, it
should be a recursive property of each of its
subsystems down to basic blocks. It is plausible that
if any subsystem does not have conceptual integrity,
the whole system cannot display it either.
Let us explain what are intensive versus
extensive quantities by an example. Suppose that our
system is a vehicle a car or a truck. A family car
typically has 4 wheels. A truck may have a bigger
number of wheels.
The weight of a vehicle is an extensive quantity,
since the weight of the system is the sum of the
weights of its components. For instance, additional
wheels increase the weight of the vehicle.
On the other hand, the speed of a vehicle is an
intensive quantity. The speed of the system is not the
sum of the speeds of its components. All the parts of
a car move at the same speed. In particular, the
tangential speed of any of the wheels is the same as
the speed of the vehicle, irrespective of the number
of wheels.
We claim that Conceptual Integrity is an
intensive quantity. It is not the sum of the conceptual
integrities of the components of a system.
4.2 Increasing Conceptual Integrity by
Components Exchange among
Modules
Let us use another physical metaphor as a further
illustration for the idea of Conceptual Integrity being
intensive.
SKY 2016 - 7th International Workshop on Software Knowledge
32
Assume a system composed of 4 sub-systems as
in Fig. 7:
1. glass container;
2. water contained by the glass;
3. sphere mostly filled with air partially
floating in the water;
4. small solid metal cube inside the sphere.
Heating the glass container by an external heat
bath, despite the different thermal conducting
properties of the sub-system materials (glass, water,
air, metal), heat energy will flow between the
different sub-systems from those with higher
temperatures to those with lower temperatures, until
the whole system reaches a uniform temperature.
The metaphor suggests that conceptual integrity
is not an extensive property, like heat energy, but an
intensive property, like temperature.
Figure 7: Physical System Metaphor The system has 4
sub-systems: a- glass container; b- water inside the glass;
c- floating sphere filled with air; d- metal cube inside the
sphere. A heat bath heats the glass container until the
temperature is uniform, causing heat energy flow among
the sub-systems.
In a software system, each sub-system may have
different computation characteristics one dealing
with data, another one with business logic, and so
on. But, moving some concepts (classes) from one
sub-system to another may increase conceptual
integrity in both sub-systems. As a consequence, one
could say that Conceptual Integrity in the whole
system is optimized by flow of concepts (classes)
among sub-systems. One should note, however, that
such flow and the hypotheses of conceptual integrity
being intensive, do not imply a single value of
conceptual integrity throughout a whole software
system.
5 DISCUSSION
We summarize the basic claim of this paper, discuss
fundamental issues, consider future work on open
issues and conclude with the main paper
contribution.
5.1 Basic Claim
Conceptual Integrity has been up to now, on one
hand been considered of fundamental importance for
software system design, on the other hand, only has
been vaguely defined.
The basic claim of this paper is that the
Modularity Matrix is a source of a formally defined
Conceptual Integrity. To this end we have provided
two lines of argumentation:
a. Formal Path from Abstract Domains
through the Modularity Matrix to
Conceptual Integrity We started from the
accepted conceptual integrity of abstract
mathematics, made a transition to generic
software with the help of Liskov
Substitution, whose meanings are conveyed
by the Modularity Matrix to a restricted set
of software systems. Using the equivalence
to the Modularity Conceptual Lattice, we
returned to "conceptual" aspects, to finally
reach Conceptual Integrity.
b. Plausibility supported by the intuitive
Principles behind Conceptual Integrity
We directly used the Modularity Matrix to
obtain the intuitive principles in a formal
way, viz. orthogonality and propriety.
Both these lines of argumentation deserve further
considerations.
The "formal path" transitions were formulated
into a series of reasonable theorems. But, in order to
have a really formal path, these theorems demand
rigorous demonstrations, or eventual reformulation
of the theorems.
The intuitive principles at least the two first
ones, viz. orthogonality and propriety have a very
neat definition by the Modularity Matrix properties.
We suggest inverting the situation: instead of trying
to derive the principles from the Matrix, take the
Modularity Matrix is the actual source of Conceptual
Integrity.
We may summarize the current situation, stating
that some promising progress has been achieved, but
additional investigation is needed to further clarify
the issues, as detailed in the next sub-section.
The Modularity Matrix as a Source of Software Conceptual Integrity
33
5.2 Fundamental Issues
a- Are hierarchies with conceptual integrity really
independent?
We have referred in sub-section 2.3 to two
independent hierarchies, one of polygons and
another one of ellipses, say a circle. However, one
may think of a circle as a regular polygon in the
limit of an infinite number of sides, enabling a
transition between two of the above hierarchies. One
can easily estimate the value of in the perimeter of
a circle 2**Radius by taking the limit of the
perimeter of a polygon inscribed in the circle, when
the number of polygon sides goes to infinity.
b- Are conceptual hierarchies stable along time?
The situation is more complex than the naïve
view of Fig. 4 would suggest. One could say that
concepts evolve see e.g. (Lakatos, 1976) in his
book on "Proofs and Refutations" which discusses
the empirical contribution to the concept evolution
of regular polyhedrons (from the initial five of
Euler). Concepts also can be said to expand along
time see e.g. (Buzaglo, 2002) according to the
terminology of his book "The Logic of Concept
Expansion".
c- What is the origin of the conceptual integrity of
major software systems?
Brooks in his books has defended the position
that only a single brilliant mind, can provide
conceptual integrity to a major work of art, say an
architect of a cathedral, or similarly to a major
engineering enterprise such as a very large software
system.
Gabriel challenges Brooks' position that a single
mind is the best originator of Conceptual Integrity
(Gabriel, 2007).
In our opinion, Brooks' position is difficult to
rationally prove for real systems. But its main
drawback is that it leaves us depending on the
existence and the opportunistic presence of a single
brilliant mind. We obviously prefer a systematic
construction of formal tools, based upon conceptual
integrity ideas, as proposed in this paper.
d- Are the Liskov Substitution Principle specific
problems detrimental to our argumentation?
We can mention two problems of the Liskov
Substitution Principle. First, how to measure the lack
of change of behavior for all programs P? Second,
the well-known problem of setter functions for
subclasses: for instance, if a 'Square' class has
inherited from the 'Rectangle' class setter functions
(like 'SetWidth' and 'SetHeigth'), independent
application of these functions may distort a Square
object into a Rectangle object. Thus, software
inheritance has subtleties in addition to those within
abstract mathematical sub-typing.
We claim that from the point of view of
conceptual integrity we can ignore these subtle
problems, and our argumentation remains valid.
e- What are the difficulties to formally interpret the
Generality property of Conceptual Integrity?
Generality, has been described as the quality that
"a single function should be usable in many ways" in
the same system. This intuitive formulation seems so
vague that its more formal interpretation is not so
clear-cut.
One possible interpretation could be the
repeated provision of the same functional by two
different structors. This should not be allowed for
the same functional in different modules. But, such
interpretation, besides being obvious in case of
inheritance among classes, is not an interesting
contribution to the overall understanding of
conceptual integrity.
5.3 Future Work
Open issues for future work include, more strictly
formalization and more extensive investigation of
the implications of the formalization, providing case
studies, to exemplify the claims.
5.4 Main Contribution
The main contribution of this work is to propose a
path to a formal definition of Conceptual Integrity,
pointing to the Modularity Matrix as a possible
source of such definition.
REFERENCES
Baldwin, C.Y. and Clark, K.B., Design Rules, Vol. I. The
Power of Modularity, MIT Press, Cambridge, MA,
USA.
Beynon, W.M., Boyatt, R.C. and Chan, Z.E., 2008.
"Intuition in Software Development Revisited", in
Proc. of 20
th
Annual Psychology of Programming
Interest Group Conference, Lancaster University, UK.
Brooks, F.P., 1995. The Mythical Man-Month Essays in
Software Engineering Anniversary Edition,
Addison-Wesley, Boston, MA, USA.
Brooks, F.P., 2010. The Design of Design: Essays from a
Computer Scientist, Addison-Wesley, Boston, MA,
USA.
SKY 2016 - 7th International Workshop on Software Knowledge
34
Buzaglo, M., 2002. The Logic of Concept Expansion,
Cambridge University Press, Cambridge, UK.
Clements, P., Kazman, R, and Klein, M., 2001. Evaluating
Software Architecture: Methods and Case Studies.
Addison-Wesley, Boston, MA, USA.
DeRosso, S.P. and Jackson, D., 2013. “What’s Wrong
with Git? A Conceptual Design Analysis”, in Proc. of
Onward! Conference, pp. 37-51, ACM. DOI:
http://dx.doi.org/10.1145/2509578.2509584.
Exman, I., 2012a. “Linear Software Models”, Proc. GTSE
1
st
SEMAT Workshop on a General Theory of
Software Engineering, KTH Royal Institute of Tech-
nology, Stockholm, Sweden. http://semat.org/wp-con
tent/uploads/2012/10/GTSE_2012_Proceedings.pdf.
Exman, I., 2012b. “Linear Software Models”, video
presentation of paper (Exman, 2012a) at GTSE 2012,
KTH, Stockholm, Sweden, Web site:
http://www.youtube.com/watch?v=EJfzArH8-ls.
Exman, I., 2014. “Linear Software Models: Standard
Modularity Highlights Residual Coupling”, Int.
Journal of Software Engineering and Knowledge
Engineering, Vol. 24, pp. 183-210. DOI:
10.1142/S0218194014500089.
Exman, I. and Speicher, D., 2015. “Linear Software
Models: Equivalence”, in Proc. ICSOFT’2015 Int.
Conference on Software Technology, pp. 109-116,
ScitePress, Portugal. DOI = 10.5220/0005557701090
116
Gabriel, R.P., 2007. "Designed as Designer". In Essay
track, ACM SIGPLAN International Conference on
Object-Oriented Programming, Systems, Languages
and Applications, Montreal, Canada. Web site:
http://dreamsongs.com/DesignedAsDesigner.html.
Ganter, B. and Wille, R., 1998. Formal Concept Analysis:
Mathematical Foundations, Springer-Verlag, Berlin,
Germany.
Ganter, B., Stumme, G. and Wille, R., 2005. Formal
Concept Analysis - Foundations and Applications.
Springer-Verlag, Berlin, Germany.
Jackson, D., 2013. “Conceptual Design of Software: A
Research Agenda”, CSAIL Technical Report, MIT-
CSAIL-TR-2013-020. URL: http://dspace.mit.edu/bit
stream/ handle/1721.1/79826/MIT-CSAIL-TR-2013-
020.pdf?sequence=2
Jackson, D., 2015. "Towards a Theory of Conceptual
Design for Software", in Proc. Onward! 2015 ACM
Int. Symposium on New Ideas, New Paradigms and
Reflections on Programming and Software, pp. 282-
296. DOI: 10.1145/2814228.2814248.
Kazman, R., 1996. “Tool Support for Architecture
Analysis and Design”, in ISAW’96 Proc. 2
nd
Int.
Software Architecture Workshop, pp. 94-97, ACM,
New York, NY, USA. DOI: 10.1145/243327.243618
Kazman, R. and Carriere, S.J., 1997. “Playing Detective:
Reconstructing Software Architecture from Available
Evidence.” Technical Report CMU/SEI-97-TR-010,
Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, PA, USA.
Krone, M. and Snelting, G., 1994. "On the Inference of
Configuration Structures from Source Code, in Proc.
ICSE-16 16
th
Int. Conf. on Software Engineering.
DOI: 10.1109/ICSE.1994.296765.
Lakatos, I., 1976. Proofs and Refutations: The Logic of
Mathematical Discovery, Cambridge University Press,
Cambridge, UK.
Liskov, B., 1988. "Keynote address - data abstraction and
hierarchy". ACM SIGPLAN Notices. 23 (5): 1734.
doi:10.1145/62139.62141
Rovetto, R., 2011. "The Shape of Shapes: an Ontological
Exploration", in Proc. SHAPES 1.0 1
st
Interdiscipli-
nary Workshop on Shapes, Karlsruhe, Germany.
The Modularity Matrix as a Source of Software Conceptual Integrity
35