Is Modeling a Treatment for the Weakness of Software Engineering?

Is Modeling a Treatment for the Weakness of Software Engineering?

DOI: 10.4018/978-1-5225-5643-5.ch012
(Individual Chapters)
No Current Special Offers


Experts' opinions exist that the way software is built is primitive. The role of modeling as a treatment for Software Engineering (SE) became more important after the appearance of Model-Driven Architecture (MDA). The main advantage of MDA is architectural separation of concerns that showed the necessity of modeling and opened the way for Software Development (SD) to become engineering. However, this principle does not demonstrate its whole potential power in practice, because of a lack of mathematical accuracy in the initial steps of SD. The question about the sufficiency of modeling in SD is still open. The authors believe that SD, in general, and modeling, in particular, based on mathematical formalism in all its stages together with the implemented principle of architectural separation of concerns can become an important part of SE in its real sense. They introduce such mathematical formalism by means of topological modeling of system functioning.
Chapter Preview


Software developers’ community understands and forcedly accepts that software development in its current state is rather art than an engineering process. This means that qualitative software is a piece-work or a craftwork. Such an item usually is expensive, and cannot be stock-produced. However, in the modern world software users want to see and to use a qualitative and relatively cheap product. This means that software development must become software engineering. The word “engineering” intends a theory approved, completely realized and reused many times in practice that gives a qualitative and relatively inexpensive end product in accurately predictable timeframes.

Software development’s way to software engineering is quite long. Things that make this way long are very different. From one viewpoint, software development lacks commonly accepted theoretical foundations. From another viewpoint, software developers do not want to use “hard” theory (especially mathematical) because in order to win on the market they must provide operating software as fast as possible and even faster, but a lack of theory just slower getting an operating product. From the third viewpoint, clients do not want to pay a powerful lot of money for a product that, first, exists only as a textual document, second, includes “intellectual” work that is hard to measure and to evaluate, and third, usually it is not the same as clients wanted. Clients cannot check how work proceeds, since they cannot see the product at whole before integration of its parts and cannot evaluate (or even understand) the size of introduced efforts.

The content of this chapter is our vision of how to shorten this long way. First, we discuss effectiveness and quality of software engineering, and then differences between traditional engineering disciplines and software engineering. Next, we consider a modeling process and discuss benefits and issues, which could and could not be solved by modeling. At the end, we discuss our vision on what must be done in order to get really revolutionary improvement of software development.

Complete Chapter List

Search this Book: