Author: saqibkhan

Function Oriented design is a method to software design where the model is decomposed into a set of interacting units or modules where each unit or module has a clearly defined function. Thus, the system is designed from a functional viewpoint.

Design Notations

Design Notations are primarily meant to be used during the process of design and are used to represent design or design decisions. For a function-oriented design, the design can be represented graphically or mathematically by the following:

Data Flow Diagram

Data-flow design is concerned with designing a series of functional transformations that convert system inputs into the required outputs. The design is described as data-flow diagrams. These diagrams show how data flows through a system and how the output is derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally understandable without specialized training, notably if control information is excluded. They show end-to-end processing. That is the flow of processing from when data enters the system to where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support data-flow diagram creation. Different ways may use different icons to represent data-flow diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a data-flow diagram. The user inputs the name of the design represented by the diagram. The report generator then finds all the names used in the data-flow diagram. It looks up a data dictionary and retrieves information about each name. This is then collated into a report which is output by the system.

Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a system. The data items listed contain all data flows and the contents of all data stores looking on the DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data elements in terms of their component data items. For example, a data dictionary entry may contain that the data grossPay consists of the parts regularPay and overtimePay.

                  grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the following reasons:

• A Data dictionary provides a standard language for all relevant information for use by engineers working in a project. A consistent vocabulary for data items is essential since, in large projects, different engineers of the project tend to use different terms to refer to the same data, which unnecessarily causes confusion.
• The data dictionary provides the analyst with a means to determine the definition of various data structures in terms of their component elements.

Structured Charts

It partitions a system into block boxes. A Black box system that functionality is known to the user without the knowledge of internal design.

Structured Chart is a graphical representation which shows:

• System partitions into modules
• Hierarchy of component modules
• The relation between processing modules
• Interaction between modules
• Information passed between modules

The following notations are used in structured chart:

Pseudo-code

Pseudo-code notations can be used in both the preliminary and detailed design phases. Using pseudo-code, the designer describes system characteristics using short, concise, English Language phases that are structured by keywords such as If-Then-Else, While-Do, and End.

Introduction:

The design and evaluation of software systems are heavily reliant on the concepts of coherence and coupling. They describe the arrangement and communication between the modules or constituents of a software system. Building software applications that are resilient, scalable, and maintainable requires an understanding of cohesion and coupling.

Introduction to Cohesion and Coupling:

The art of designing manageable and effective software components known as modularization is shaped by coupling and cohesion in software engineering.

Module interdependence is defined by coupling whereas component unity is measured by cohesion. Achieving high cohesion and low coupling encourages modular structures that are understandable and maintainable. By navigating complexity, developers can enhance testing, scalability, and teamwork through this mutually beneficial relationship. These guidelines affect customer satisfaction and project management throughout the whole software lifecycle.

Module Coupling

In software engineering, the coupling is the degree of interdependence between software modules. Two modules that are tightly coupled are strongly dependent on each other. However, two modules that are loosely coupled are not dependent on each other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations between the modules. That is, the coupling increases as the number of calls between modules increase or the amount of shared data is large. Thus, it can be said that a design with high coupling will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items such as structure, objects, etc. When the module passes non-global data structure or entire structure to another module, they are said to be stamp coupled. For example, passing structure variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed data format, communication protocols, or device interface. This is related to communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch from one module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationships between pieces of functionality within a given module. For example, in highly cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as “high cohesion” or “low cohesion.”

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module form the components of the sequence, where the output from one component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the module refer to or update the same data structure, e.g., the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module are all parts of a procedure in which particular sequence of steps has to be carried out for achieving a goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the methods must be executed in the same time, the module is said to exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a similar operation. For example Error handling, data input and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that are associated with each other very loosely, if at all.

Difference between Cohesion & Coupling:

Aspect	Coupling	Cohesion
Definition	Level of interdependence among a systems modules or constituent parts.	The degree of focus and relatedness among a module or component.
Focus	Interaction amongst modules.	Elements that make up a module.
Impact on Change	One module change may have an effect on others.	Modifications are contained within a module.
Flexibility	Since changes are likely to spread a high coupling, decreases system flexibility.	As changes are localized high cohesion increases system flexibility.
Maintenance	Due to the frequent changes high coupling makes maintenance more difficult.	AS changes are limited maintenance is made easier by high cohesion.
Testing	Isolating and testing coupled modules is more difficult.	Cohesive modules functionality is well-contained testing them is simpler.
Reuse	Because of dependencies coupled modules are less reusable.	Cohesive modules clear and targeted functionality makes them more reusable.
Dependency	Module dependency is represented by coupling.	Cohesion stands for the purpose and unity of a module.
Design Goal	To reduce interdependencies, aim for low coupling.	For modules to be clear and focused strive for high cohesion.
Objective	For system stability minimize dependencies and interactions.	elemental groupings to accomplish a clear goal.
System Impact	Cascading failures and rigid architectures can result from high coupling.	Adaptable architectures and maintainability are encouraged by high cohesion.

Conclusion:

The quality and maintainability of software systems are greatly impacted by the fundamental software engineering concepts of cohesion and coupling. Strong module cohesion guarantees focused, unambiguous functionality which facilitates the understanding testing and maintenance of code.

Aiming for low coupling and high cohesion together results in systems that are more adaptable, resilient, and changeable. A well-designed software system achieves maintainability, reusability, and long-term success by striking a harmonious balance between coupling and cohesion. Software engineers can create systems that are not only functional but also flexible enough to adapt to changing user demands and technological breakthroughs by comprehending and putting these principles into practice.

Software design principles are concerned with providing means to handle the complexity of the design process effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant problem, divide the problems and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand
2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They have to cooperate and communicate to solve the problem. This communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity increases

---

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level without bothering about the internal details of the implementation. Abstraction can be used for existing element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction

1. A module is specified by the method it performs.
2. The details of the algorithm to accomplish the functions are not visible to the user of the function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object Oriented design approaches.

---

Modularity

Modularity specifies to the division of software into separate modules which are differently named and addressed and are integrated later on in to obtain the completely functional software. It is the only property that allows a program to be intellectually manageable. Single large programs are difficult to understand and read due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

• Each module is a well-defined system that can be used with other applications.
• Each module has single specified objectives.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

• It allows large programs to be written by several or different people
• It encourages the creation of commonly used routines to be placed in the library and used by other programs.
• It simplifies the overlay procedure of loading a large program into main storage.
• It provides more checkpoints to measure progress.
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines must be written, and more documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by allowing parallel development of various parts of a system. We discuss a different section of modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that perform only one kind of task and do not excessively interact with other modules. Independence is important because it makes implementation more accessible and faster. The independent modules are easier to maintain, test, and reduce error propagation and can be reused in other programs as well. Thus, functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

• Cohesion: It measures the relative function strength of a module.
• Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized by the design decisions that protect from the others, i.e., In other words, modules should be specified that data include within a module is inaccessible to other modules that do not need for such information.

The use of information hiding as design criteria for modular system provides the most significant benefits when modifications are required during testing’s and later during software maintenance. This is because as most data and procedures are hidden from other parts of the software, inadvertent errors introduced during modifications are less likely to propagate to different locations within the software.

---

Strategy of Design

A good system design strategy is to organize the program modules in such a method that are easy to develop and latter too, change. Structured design methods help developers to deal with the size and complexity of programs. Analysts generate instructions for the developers about how code should be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components and then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

Introduction:

Software design is the process of constructing software methods, functions, objects, the overall structure and interaction of your code, so that the functionality produced satisfies the needs of your users. There are many different methods for designing software. Different developers have different preferences for different design levels either up front or during the execution phase. In general, the overall design should be carefully considered and reviewed before starting to code. Early in the development cycle it is simpler to test various designs and identify issues than to make a big design change after the majority of the code has been written. To begin let’s review the definition of software design in software engineering.

What is Software Design:

Software design is a mechanism to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. It deals with representing the client’s requirement, as described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable using programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle), which moves the concentration from the problem domain to the solution domain. In software design, we consider the system to be a set of components or modules with clearly defined behaviors & boundaries.

Objectives of Software Design

Following are the purposes of Software design:

1. Correctness:Software design should be correct as per requirement.
2. Completeness:The design should have all components like data structures, modules, and external interfaces, etc.
3. Efficiency:Resources should be used efficiently by the program.
4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily maintainable by other designers.

Software Design Levels:

In software design there are three levels.

1. Architecture Design:

An architecture is the overall structure of a system and how that structure provides conceptual integrity to the system. According to the architectural design the software is a system made up of many interrelated parts. At this point the designers obtain a broad understanding of the domain of the suggested solution.

2. High-level design:

By breaking down the architectural design’s “single entity-multiple component” concept the high-level design presents a less abstract view of subsystems and modules and illustrates how they interact with one another. Implementing the system and its components as modules is the focus of high-level design. It acknowledges each subsystem modular design in addition to their connections and interactions with one another.

3. Detailed Design:

Following the completion of the high-level design the detailed design process starts. At this stage of software design every module is thoroughly examined to determine the data structures and algorithms that will be employed. Ultimately the stages results are recorded in a module specification document. It outlines each modules interface with other modules as well as its logical structure.

Principles of Software Design:

Let’s examine a few software design ideas that help a software engineer build a model of the system or software product that needs to be developed. Before creating a software system, the following concepts should be understood.

Abstraction:

Object-oriented programming (OOP) languages include abstraction as one of their core ideas. Its main goal is to handle complexity by keeping the user unaware of internal details. This enables the user to construct increasingly complex reasoning on top of the provided abstraction without needing to comprehend or even consider all of the hidden complexity.

Flexibility:

To reduce the complexity of a system or project modularity means dividing it into smaller parts. In design, modularity also means breaking a system up into smaller components that can be constructed separately and then utilized in different systems for various functions. It is sometimes necessary to divide software into modules in order to deal with monolithic software which is challenging for software engineers to understand. Modularity in design has consequently emerged as a crucial and popular trend.

Architecture:

The design choices pertaining to the overall structure and functionality of a system are represented by its software architecture. Architecture helps stakeholders understand and assess how the system will achieve important features like security, availability, and modifiability. It outlines the relationships and communication between the various parts that make up a software system. For the development team it serves as a foundation and a blueprint for the software application.

Enhancement:

Refinement is the process of eliminating impurities and raising something caliber. Building or presenting the software or system in a detailed way which entails expanding on a system or software is the idea behind software design refinement. Furthermore, refinement is crucial for locating and fixing any potential mistakes.

Design Patterns:

Within a specific software design context, a software design pattern is a general reusable solution to a problem that frequently arises. Representing some of the best techniques used by seasoned object-oriented software engineers they serve as templates to address typical software engineering issues. In object-oriented systems a design pattern is a general design that addresses a recurrent design problem in a methodical manner. It covers the issue, the solution, when to apply it, and the consequences. Also, it offers examples and implementation advice.

Data (or) Information Hiding:

In its most basic form, information hiding is the act of keeping information hidden from unauthorized parties. When designing software information hiding is achieved by structuring modules so that data obtained or stored in one module is hidden and inaccessible by other modules.

Refactoring:

Refactoring is the process of rearranging code so that it works as intended. By making small adjustments that don’t impact the codes external behavior refactoring attempts to enhance internal code. Code is refactored by computer programmers and software developers to enhance the software implementation, structure, and design. Refactoring thus reduces complexity while improving code readability. Hence, refactoring can help software engineers find errors or weaknesses in their code.

Conclusion:

In software design user requirements are transformed into a format that programmers can use for coding and implementation. Using a programming language, it aims to transform the client’s requirements as stated in the Software Requirement Specification (SRS) document into a format that is simple to implement. During the software design phase of the Software Design Life Cycle (SDLC) the emphasis moves from the problem domain to the solution domain. It tries to provide guidance on how to fulfill the SRSs requirements. Accuracy, completeness, efficiency, flexibility, consistency, and maintainability are the goals of the software design process.