Issue link: https://wardsworld.wardsci.com/i/1488288
3 architects, civil engineers, and electricians. As such, their nota- tion is aimed at highlighting what is important to them, while minimizing the other aspects of the design. However, regard- less of the notation methodology used, the overall objective is to convey a clear understanding of how the pieces fit together before considering how they will be implemented. The main principles used are those of abstraction, modularity, informa- tion hiding, and coupling and cohesion. Abstraction is concerned with the identification of key objects and functionality that might be reused throughout the system. Closely associated with abstraction is the principle of modularity. A module is a simple unit of the system that accomplishes a particular subtask, has a well-defined inter- face, and can be independently tested. It is the totality and the interplay of these modules that allow a particular functionality of the overall system to be achieved. Modules can be thought of as "black boxes" in which the internal details are hidden from other modules. However, modules need to interact, and there- fore each one of them has a "public" component that allows communication with the others. In the composition of each module, or even larger units, it is necessary to take into account the relationships of its internal components, or cohesiveness. We can think of cohesiveness as a measure of how well all the components are working together for a common goal. A prag- matic approach for determining whether a module is perform- ing a single task is to try to describe its functionality through a single sentence that contains a single subject, verb, and object. If this is not possible, then the module is performing more than one task and needs to be rewritten. A tighter relationship, or high cohesiveness, in a module is desirable because it makes the module's functionality easier to understand, test, and docu- ment. In addition to considering how the internal components of a module interact to accomplish a task, it is crucial to consider how the different modules interact with one another (cou- pling). Coupling can be thought of as a measure of the strength of the linkages between modules, based on the amount and type of information that they exchange—that is, how closely connected the modules are. Minimally coupled or loosely coupled modules are independent of each other. In other words, a minimal amount of required information is exchanged between the modules. In this regard, minimal coupling is a very desirable goal in software design. The notions of coupling and cohesion are related. "Low coupling" generally correlates well with high cohesion, and vice versa. Low coupling is regarded as an indicator of good design. If high cohesion among modules also exists, then the desirable goals of high readability and maintainability of any individual system software component, as well as of the overall system, will be achieved. Coding The coding phase of the software development life cycle is concerned with implementing the software components that will satisfy the system requirements as stated in the SRS docu- ment using one or more suitable programming languages. The coding of the system may involve the use of either a high- or a low-level language. High-level languages that may be used for writing appropriate code can be of different types, such as functional, declarative, imperative, or object oriented. Low-level languages that can be used are machine or assembly languag- es. For pragmatic reasons, most systems are generally devel- oped using a combination of high-level languages; however, when fast performance or minimum size of executable code (footprint) is required, the use of a low-level language— or a high-level language that allows direct interaction with the hardware—is desirable. As a result of this programming pro- cess, the deliverable for this phase is a working version of the envisioned system. The coding phase considers the essential issues of quality, performance, and debugging. Testing Although the testing phase can be viewed as an indepen- dent phase of the software development life cycle, it is highly integrated with the coding phase. This depends, in part, on the testing approaches used, as described later in this section, and the fact that programmers continually test their modules. The main objective of the testing phase is to examine the work- ing version of the system to determine whether it meets the system requirements as specified in the SRS document. It aims to find where the system fails to meet these specifications as the result of an error, a bug, or an oversight related to require- ment implementation. All functionalities of the system must be mapped to a particular set of requirements, and vice versa. This is necessary not only for coding, but also for all life-cycle phases and their deliverables. The software testing process is often divided into subphases. The first subphase is unit testing of the software developed by a single programmer. The second subphase is integration testing, in which all units are combined and tested as a single group and the test cases are developed directly from the SRS document. System testing can be done in either a top-down or bottom-up fashion. In top-down testing, high-level routines are implemented and tested first and then used as a testing environment for the lower-level routines. This is called the test harness. Testing the system in a bottom-up fashion proceeds by first developing low-level routines and testing them, then progressively combining these routines and testing them as parts of larger and larger program units. In practice, when both methods are used concurrently, the process is called sandwich testing. Final acceptance of the system is done by its intended Software Engineering (continued) + ward ' s science