class: center, middle .center[] # SAD Course: Cohesion & Coupling Sharif University of Technology<br/> Instructor: [S. M. Masoud Sadrnezhaad](https://twitter.com/smmsadrnezh) --- # Some Basic Terms - **Software** is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be **collection** of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. - **Software engineering** is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product. - In Software engineering and systems engineering, a **functional requirement** defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs. - In systems engineering and requirements engineering, a **non-functional requirement** is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. ??? * Security * Logging * Performance * Configurability * Flexibility * Robustness * Reliability -> Mean Time Between/To Failures * Maintainability * Portability * Scalability --- # Need of Software Engineering The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. * **Large software-** It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process. * **Scalability-** If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. * **Cost-** As hardware industry has shown its skills and huge manufacturing has lower down he price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. * **Dynamic Nature-** The always growing and adapting nature of software hugely depends upon the environment in which user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role. * **Quality Management-** Better process of software development provides better and quality software product. --- # Software Development Life Cycle .center[] --- # Software Development Life Cycle (Contd) #### Communication This is the first step where the user initiates the request for a desired software product. He contacts the service provider and tries to negotiate the terms. He submits his request to the service providing organization in writing. #### Requirement Gathering The team holds discussions with various stakeholders from problem domain and tries to bring out as much information as possible on their requirements. #### Feasibility Study After requirement gathering, the team comes up with a rough plan of software process. At this step the team analyzes if a software can be made to fulfill all requirements of the user and if there is any possibility of software being no more useful. ??? Communication RFP Requirement Gathering * Surveys -> Organization may conduct surveys among various stakeholders by querying about their expectation * Questionnaires * already has some software to perform certain operation * Domain Analysis -> expert people in the domain * Brainstorming * Prototyping * Observation Feasibility Study / Risk / Test * Technical * Legal * Operational -> fits in with the existing business environment * Schedule * Financial * Human Factor --- # Software Development Life Cycle (Contd) #### System Analysis The present system is investigated and its specifications documented. They should contain our understanding of HOW the present system works and WHAT it does. The project team analyzes the scope of the project and plans the schedule and resources accordingly. #### Software Design Next step is to bring down whole knowledge of requirements and analysis on the desk and design the software product. The inputs from users and information gathered in requirement gathering phase are the inputs of this step. The output of this step comes in the form of two designs; logical design and physical design. #### Coding This step is also known as programming phase. The implementation of software design starts in terms of writing program code in the suitable programming language and developing error-free executable programs efficiently. --- # Software Development Life Cycle (Contd) #### Testing Testing, verification and validation of the system just built. #### Integration Software may need to be integrated with the libraries, databases and other program(s). #### Implementation This means installing the software on user machines. At times, software needs post-installation configurations at user end. --- # Software Development Life Cycle (Contd) #### Operation and Maintenance If required, the users are trained on, or aided with the documentation on how to operate the software and how to keep the software operational. The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. #### Disposition As time elapses, the software may decline on the performance front. It may go completely obsolete or may need intense upgradation. ??? Corrective Maintenance - This includes modifications and updations done in order to correct or fix problems, which are either discovered by user or concluded by user error reports. Adaptive Maintenance - This includes modifications and updations applied to keep the software product up-to date and tuned to the ever changing world of technology and business environment. Perfective Maintenance - This includes modifications and updates done in order to keep the software usable over long period of time. It includes new features, new user requirements for refining the software and improve its reliability and performance. Preventive Maintenance - This includes modifications and updations to prevent future problems of the software. It aims to attend problems, which are not significant at this moment but may cause serious issues in future. Software Development Paradigm The software development paradigm helps developer to select a strategy to develop the software. Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on. <!--.center[]--> --- # Software Design **Software design** is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. It moves the concentration from problem domain to solution domain and tries to specify how to fulfill the requirements mentioned in SRS. **Modularization** is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. When a software program is modularized, its tasks are divided into several modules based on some characteristics. Modules are set of instructions put together in order to achieve some tasks. They are though, considered as single entity but may refer to each other to work together. There are measures by which the quality of a design of modules and their interaction among them can be measured. These measures are called coupling and cohesion. --- # Cohesion & Coupling In computer programming, **cohesion** refers to the degree to which the elements inside a module belong together. In software engineering, **coupling** is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules. We consider cohesion to be a good thing because it makes software easier to understand, reduces the effects a change on one part of the system has on the rest of the system, and it allows us to reuse code within our application. We like loosely coupled software because it reduces the impact of a change in one module across other modules. Loosely coupled software is also easier to reuse, because it doesn’t have many other dependencies to be included. ### Sounds like they are trying to achieve very similar goals And they are. For the most part high cohesion and loose coupling go together. --- # Levels of Cohesion * Low Cohesion (Highly Undesirable) * Coincidental Cohesion * Logical Cohesion * Temporal Cohesion * Moderate Cohesion (Acceptable) * Procedural Cohesion * Communicational Cohesion * Sequential Cohesion * High Cohesion (Desirable) * Functional Cohesion --- # Low Cohesion - Highly Undesirable Modules with *low* levels of cohesion are highly undesirable and should be modified or replaced. ### Coincidental Cohesion A module that only has coincidental cohesion is one supporting tasks that have no meaningful relationship to one another. As an example, a module supporting the following tasks: * Fix Car * Bake Cake * Walk Dog * Fill our Astronaut-Application Form * Get out of Bed * Go the the Movies --- # Low Cohesion - Highly Undesirable (Contd) ### Logical Cohesion A logically cohesive module is one whose elements contribute to activities of the same general category in which the activity or activities to be executed are selected from outside the module. Someone contemplating a journey might compile the following list: * Go by Car * Go by Train * Go by Boat * Go by Plane What relates these activities? They're all means of transport, of course. But a crucial point is that for any journey, a person must choose a specific subset of these modes of transport. It's unlikely anyone would use them all on any particular journey. --- # Low Cohesion - Highly Undesirable (Contd) ### Logical Cohesion (Contd) A logically cohesive module contains a number of activities of the same general kind. To use the module, we pick out just the piece(s) we need. Thus, a logically cohesive module is a grab bag of activities. A module with a name like **Do all System I/O** is probably a module that is only logically cohesive. --- # Low Cohesion - Highly Undesirable (Contd) ### Temporal Cohesion A temporally cohesive module is one supporting tasks that are all related in time. * Put out Milk Bottles * Put out Cat * Turn off TV * Brush Teeth These activities are (only) related by the fact that you do them all late at night, just before you go to bed. A module whose name is "Do All Startup Activities," or "Do All Shutdown Activities," might only have temporal cohesion. --- # Moderate Cohesion - Acceptable Modules with **moderate cohesion** are acceptable, but not ideal. Consider modifying them, but note that changes might introduce other design problems, so that you might best leave these as they are. ### Procedural Cohesion A module with (only) procedural cohesion is one supporting different and possibly unrelated activities, in which control passes from one activity to the next. As an example, a module supporting the activities: (Prepare for Holiday Meal) * Clean Utensils from Previous Meal * Prepare Turkey for Roasting * Make Phone Call * Take Shower * Chop Vegetables * Set Table This is a bit better than **temporal cohesion,** since we know that there's a fixed **linear ordering** of the activities. However, there's still not much reason for putting all these activities together into one module. --- # Moderate Cohesion - Acceptable (Contd) ### Communicational Cohesion All the activities it supports use the same input or output data - or access and modify the same part of a data structure. As an example, a module supporting the activities: * Find Title of Book * Find Price of Book * Find Publisher of Book * Find Author of Book Another example would be a module providing the entire interface to a stack - supporting activities Push, Pop, an Empty. We've now left the kind of **linear ordering**, or **containment relationships**, that we've had for levels of cohesion until now. --- # Moderate Cohesion - Acceptable (Contd) ### Sequential Cohesion One whose elements are involved in activities such that output data from one activity serves as input data to the next. As an example, a module supporting the activities: * Clean Car Body * Fill in Holes in Car * Sand Car Body * Apply Primer --- # High Cohesion - Desirable Modules with high cohesion are extremely desirable, and don't need to be changed (except to correct other kinds of design problems). ### Functional Cohesion Activities needed for the execution for one and only one problem-related task. As an example, modules with names: * Compute Cosine of Angle * Verify Alphabetic Syntax * Read Transaction Record * Determine Customer Mortgage Repayment * Compute Point of Impact of Missile * Calculate Net Employee Salary * Assign Seat to Airline Customer --- # Levels of Coupling It's not important that you determine the precise level of coupling for a given set of modules - but it is important to decide whether this is unnacceptably high, high but unavoidable, acceptable, or ideal. * Highest Level of Coupling (Unacceptable) * Content Coupling * High Levels of Coupling (Undesirable but Possibly Unavoidable) * Common Coupling * External Coupling * Moderate Levels of Coupling (Acceptable) * Control Coupling * Low Coupling (Desirable) * Stamp Coupling * Data Coupling * Lowest Level of Coupling --- # Highest Coupling ### Content Coupling Two (or more) modules exhibit content coupling if one refers to the *inside* - the *internal* or *private* part - of the other in some way. As an example: * Module A *branches* or *falls through* into Module B (by containing a GOTO statement that transfers control somewhere into the middle of Module B); * Module A refers to, or changes, Module B's internal (and, again, *private*) data * Module A changes one of the statements in Module B's object code. It could said with some justification that the above examples do involve *sick programming practices.* Fortunately, high level programming languages make these difficult. *Optimization* is sometimes cited as an excuse for these. This is the only plausible excuse for these I can think of you might consider resorting to some of these only after every other sensible strategy has failed to produce a program that meets the system's performance requirements. --- # High Coupling These levels of coupling are undesirable, but may also be unavoidable. You should try to minimize the use of these, and use *information hiding* - developing and using well-defined interfaces - to limit the effects of these. ### Common Coupling Two or more modules exhibit **common coupling** if they refer to the same global data area - that is, to something that corresponds to a data store on a DFD or a *register* that must be shared by several processes. ### External Coupling Two or more modules exhibit **external coupling** if they share direct access to the same I/O device or are *tied to the same part of the environment external to software* in some other way. --- # Moderate Coupling This level of coupling is perfectly acceptable. ### Control Coupling Two modules exhibit control coupling if one (*module A*) passes to the other (*module B*) a piece of information that is intended to control the internal logic of the other. This will often be a value used in a test for a case statement, if-then statement, or while loop, in module B's source code. This is perfectly acceptable. However, the program architecture should make it clear that module A does control module B in this way - preferably by having module A call module B directly, or vice-versa. Then, when the system is combined together (*integrated*) and tested, the two modules will be combined together, and tested as one unit, relatively early in the process - so that any problems arising from this *control coupling* will be detected early on. --- # Low Coupling The most desirable kind of ``coupling'' of modules, if they're to be connected at all ### Stamp Coupling This is a special case (or extension) of data coupling. One passes directly to the other a *composite* piece of data - that is, a piece of data with meaningful internal structure - such as a record (or structure), array, or (pointer to) a list or tree. --- # Low Coupling (Contd) ### Data Coupling One calls the other directly and they communicate using *parameters* - a simple list of inputs and outputs (and inputs that are modified) With each parameter being an *elementary* piece of data, such as an integer, floating point number, boolean value, member of an enumerated set, character, or (maybe) character string. The modules exhibit stamp coupling if *composite* data types are used for parameters as well. Ideally, this is the usual type of interaction between modules that need to communicate at all: Modules with higher levels of coupling this are only used *when necessary.* --- # Lowest Level of Coupling Modules A and B have the lowest possible level of coupling - no coupling at all - if they have no direct communication and are also not *tied together* by shared access to the same global data area or external device. This is the ideal situation, because it implies that A and B be implemented, tested, and maintained (almost) completely independently; neither will affect the behaviour of the other Of course, it is necessary to have some communication among modules in any nontrivial system. --- # References * http://pages.cpsc.ucalgary.ca/~eberly/Courses/CPSC333/Lectures/Design/cohesion.html * http://pages.cpsc.ucalgary.ca/~eberly/Courses/CPSC333/Lectures/Design/coupling.html * Page-Jones' book, The Practical Guide to Structured Systems Design * Pressman's text, Software Engineering - A Practitioner's Approach discusses functional independence, including cohesion and coupling, in Sections 10.4.2 - 10.4.4 (pages 333-338). * https://simpleprogrammer.com/2010/11/04/back-to-basics-cohesion-and-coupling-part-1/ * https://www.tutorialspoint.com/software_engineering/software_engineering_overview.htm * https://www.tutorialspoint.com/software_engineering/software_development_life_cycle.htm * https://www.tutorialspoint.com/software_engineering/software_design_basics.htm --- class: center, middle .center[] # Thank you. Any questions?