<< Chapter < Page | Chapter >> Page > |
Before setting up to the task of studying and applying Software Architecture, it is convenient to know where – within the range of Software Engineering Body of Knowledge – Software Architecture should be placed as a discipline. Besides, the implementation of Software architectural design is the first of two activities that comprise the Software Design Knowledge Area (the other activity is that of software detailed design). As part of Software Design, Software Architecture is a mixture of method and creativity. Software Architecture lies beyond the range of this book whose purpose does not include the teaching of creativity. Creativity is something that results from experience, thus it is not the purpose of this book teach it. However, the authors seek to impart the knowledge needed for you to create software system architectures.
A sound knowledge of the fundamentals of Software Design is certainly needed for you to take up the material covered in this book. Therefore, this chapter will provide you with an overall view of these fundamentals, expounding them further by setting up an underlying, supportive foundation to help you recognize both the relevance and the advantages of software design. In other words, it will provide you with the necessary knowledge that will enable you to:
The relevance of the practice (and, therefore, of the study) of Software Design can be explained by the ever-increasing complexity of software systems. Because of such complexity, the risk of building a system that will not meet its goals is indeed too high.
In order to avoid such a risk, the rule of thumb of any engineering process for building a complex artifact is to build it according to a pre-established plan, e.g. , to design it before building it. Therefore, the purpose of design is twofold. One is to allow you to build models that can be analyzed and evaluated against their aimed objectives before they are actually built; and the other is to serve as a guide for the artifact assemblage after it has passed both the analysis and the evaluation phases.
There are several reasons for designing an artifact before building it. The following paragraphs describe some of them.
Design enables early evaluation. The building process of an artifact can be very expensive in terms of time and money. Because it helps to ensure that the right thing is being built, those involved in this process desire the possibility of early evaluation. Since the products of design process often permit this kind evaluation and it often costs less than actually building the artifact, designing and early evaluating the artifact before building are recommended in order to save time and money.
Notification Switch
Would you like to follow the 'Software architecture for experts-to-be' conversation and receive update notifications?