Unit - 4
Design
Throughout the history of software engineering, design principles have evolved. Each principle provides a basis for the software designer from which more advanced methods of design can be implemented. Below is a brief description of essential principles in software design that encompass both conventional and object-oriented software creation.
A design pattern defines a design framework that addresses a specific design problem within a particular context and in the midst of "forces" that may influence the way the pattern is implemented and used. Essential principles in software design that encompass both conventional and object-oriented software creation.
Abstraction
When you consider every problem to be a modular solution, several levels of
abstraction may be posed. At the highest level of abstraction, using the language of the problem setting, a solution is described in general terms. A more detailed explanation of the solution is provided at lower levels of abstraction. Finally, the solution is described in a way that can be explicitly applied at the lowest level of abstraction.
A procedural abstraction relates to a set of instructions that have a particular and restricted purpose. These functions are indicated by the name of a procedural abstraction, but precise specifics are suppressed. A data abstraction is a set of named data representing a data object.
Architecture
The architecture of the software alludes to "the general layout of the software and The ways in which the context provides a structure with logical integrity” .Architecture is, in its simplest form, the arrangement or organisation of software components (modules), the way in which these components communicate, and the data structure used by the components.
A collection of properties is defined by Shaw and Garlan as part of an architectural design:
Structural Properties: This part of the description of architectural architecture describes the Device components (e.g., modules, objects, filters) and the way these components are packaged and communicate with each other.
Extra Functional Properties: The definition of architectural design should discuss how the build architecture achieves requirements for performance, power, reliability, protection, adaptability, and other device characteristics.
Families of related system: Repeatable patterns can be used in architectural design. In the configuration of families of identical structures, these are frequently encountered. The architecture should, in turn, have the capacity to reuse architectural building blocks.
Design Patterns
A pattern is a so-called insight nugget that transmits the essence of a known in a certain context, in the midst of conflicting problems, solutions to a recurrent problem. Stated
A design pattern defines a design framework that addresses a specific design problem within a particular context and in the midst of "forces" that may influence the way the pattern is implemented and used. Each design pattern is intended to provide a definition that helps a designer to decide
- If the pattern applies to the current job is
- If they can reuse the pattern (hence, saving design time)
- If the model may serve as a guide to creating a pattern that is similar, but functionally or structurally different.
Separation of Concerns
Separation of concerns is a principle of design which implies that if it is subdivided into pieces that can each be solved and/or optimized separately, any complex problem can be addressed more easily. If the perceived complexity of p1 is greater than the perceived complexity of p2, for two problems, p1 and p2, it follows that the effort needed to solve p1 is greater than the effort required to solve p2. This outcome, as a general case, is intuitively evident. It takes more time for a complex problem to be solved. It also follows that when two issues are combined, the perceived complexity is always greater than the amount of the perceived complexity when each is taken separately. This leads to a divide-and-conquer strategy; when you break it into manageable bits, it is easier to solve a complicated problem. With respect to device modularity, this has significant consequences.
Modularity
The most common manifestation of separation of worries is modularity.
Software is split into separately named and addressable components that are combined to fulfil problem requirements, also called modules.
Modularity is the single attribute of software that enables a programme to be intellectually manageable," it has been stated." The number of paths of management, reference period, number of variables, and overall complexity will make comprehension almost impossible. You should split the design into several modules in almost all situations, aiming to make comprehension simpler and, as a result, reduce the cost of creating the programme.
|
Fig 1: modularity
Information Hiding
The theory of hiding information implies that modules are "Characterized by design decisions that hide from everyone else." In other words, modules should be defined and configured so that information stored within a module (algorithms and data) is inaccessible to other modules that do not require such information.
Hiding means that it is possible to achieve successful modularity by specifying a series of independent modules that interact with each other only with the information required to achieve software functionality.
Abstraction helps describe the groups that make up the software that are procedural (or informational). Hiding defines and enforces access restrictions within a module and any local data structure used by the module for both procedural information.
Functional Independence
The idea of functional independence is a direct outgrowth Separation of interests, modularity, and the principles of hiding knowledge and abstraction.
The creation of modules with "single minded" features and an "aversion" to undue contact with other modules achieves functional independence. In other words, you can design software such that each module addresses a particular subset of requirements and, when viewed from other sections of the programme structure, has a simple interface.
Two qualitative measures are used to determine independence: cohesion and coupling
A single task is carried out by a cohesive module, requiring little contact with other modules in other parts of a programme. Simply put, a coherent module can do only one thing (ideally).
Although you should always aim for high cohesion (i.e. single-mindedness), making a software component perform several functions is also important and advisable.
In a software structure, coupling is an indication of interconnection between modules. Coupling relies on the complexity of the interface between modules, the point at which a module entry or reference is made, and what data moves through the interface.
Refinement
Stepwise refinement is a technique for top-down design. The creation of a software is
By successively refining procedural information levels. A hierarchy is defined by stepwise decomposing a macroscopic function statement (a procedural abstraction) until programming language statements are reached.
In reality, refinement is a process of elaboration that starts with a function statement (or knowledge description) that is described at a high level of abstraction. As design advances, sophistication allows you to uncover low-level information.
Aspects
A collection of "concerns" is discovered as the review of requirements occurs. These “Include requirements, use cases, features, data structures, quality of service problems, variants, boundaries of intellectual property, collaborations, trends and contracts".
Ideally, a model of requirements should be designed in a way that allows you to separate each problem (requirement) so that it can be independently considered. However, in fact, some of these problems span the entire structure and cannot be easily compartmentalized.
Refactoring
For several agile processes, a significant design task is the refactoring of a Technique of reorganization that simplifies a component's design (or code) without modifying its purpose or behaviour. "Refactoring is the process of modifying a software system in such a way that it does not change the code [design]’s behaviour, but improves its internal structure."
The current design is checked for duplication, unused design components, ineffective or redundant algorithms, improperly designed or inadequate data structures, or some other design flaw that can be changed to create a better design when software is refactored. The effect would be software that is easier to integrate, easier to evaluate, and easier to manage.
Object-Oriented Design Concept
In modern software engineering, the object-oriented (OO) paradigm is commonly used. Concepts of OO architecture, such as classes and artefacts, inheritance, Messages, and, among others, polymorphism.
Design Classes
You can identify a collection of design classes as the design model evolves,
By providing design specifics that will allow the classes to be implemented, and implementing a software infrastructure that supports the business solution, they refine the study classes. It is possible to create five different categories of design classes, each representing a different layer of design architecture.
User interface classes - All abstractions that are required for human computer interaction are specified by user interface classes (HCI). HCI exists in certain instances within the context of a metaphor (e.g. a cheque book, an order form, a fax machine), and the interface design classes can be visual representations of the metaphor components.
Business domain classes - Sometimes, business domain classes are refinements of the classes of study. The classes specify the attributes and services (methods) needed to implement a certain business domain component.
Process classes - Lower-level business abstractions needed to handle the business domain classes completely are implemented by process classes.
Persistent classes - Persistent classes describe stores of data (e.g. a database) that will survive after the programme execution.
System classes - System classes incorporate programme management and control functions that allow the system to run and interact with the outside world and within its computing environment.
They describe four features of a well-formed class of design:
- Complete and sufficient
- Primitiveness
- High cohesion
- Low coupling
Key takeaway:
- A procedural abstraction relates to a set of instructions that have a particular and restricted purpose.
- Architecture is, in its simplest form, the arrangement or organisation of software components (modules), the way in which these components communicate, and the data structure used by the components.
- A design model systematically names, motivates, and demonstrates a general design that solves a recurring design issue in object-oriented systems .
- Separation of concerns is a principle of design which implies that if it is subdivided into pieces that can each be solved.
- Modularity is the single attribute of software that enables a programme to be intellectually manageable.
- Hiding information implies that modules are "Characterized by design decisions that hide from everyone else.
- The idea of functional independence is a direct outgrowth Separation of interests, modularity, and the principles of hiding knowledge and abstraction.
- Stepwise refinement is a technique for top-down design.
- You can identify a collection of design classes as the design model evolves.
There are also two stages to the design process for software systems. At the first step, the emphasis is on determining which modules, based on SRS (Software Requirement Specification), are necessary for the system and how the modules should be interconnected.
Function Oriented Design is a software design approach in which the design is broken down into a series of interacting units in which each unit has a clearly specified function.
Procedure:
Start with an overview of what the software / programme does at a high level. Refine each element of the description one at a time by defining the functionality of each part in greater detail. The top-down structure contributes to these points.
|
Fig 2: Design strategy
Function Oriented design strategies:
The following are Feature Driven Design Strategies:
- Data Flow Diagram:
For any process or system, a data flow diagram (DFD) maps out the information flow. To display data inputs, outputs, storage points and the routes between each destination, it uses specified symbols such as rectangles, circles and arrows, plus short text labels.
- Data Dictionary:
Data dictionaries are simply repositories that store all of the data items specified in DFDs with details. Data dictionaries contain data objects at the demand level. Item Name, Aliases (Other Item Names), Description/Purpose, Related Data Objects, Set of Values, Data Structure Definition/Form are the data dictionaries.
- Structure Chart:The hierarchical representation of the scheme divides the structure into black boxes (functionality is known to users but inner details are unknown). From top to bottom and left to right, components are read. The so-called module is regarded as a black box when a module calls another, passing the necessary parameters and obtaining results.
|
Fig 3: Structure chart
- Pseudo Code: In short English, Pseudo Code is a device description like phrases that explain the function. Keywords and indentations are used. For flow maps, pseudo codes are used as a substitute. It reduces the required amount of documentation.
Using pseudo-code, the designer uses short, succinct, English language stages to define device features organized by keywords such as If-Then-Else, While-Do, and End.
Key takeaway:
- Function Oriented Design is a software design approach in which the design is broken down into a series of units in which each unit has a specified function.
- There are also two stages to the design process for software systems.
Object oriented design deals around the entities and their properties instead of functions involved in the software system. This design pattern focuses on entities and its properties. The whole concept of software solution revolves around the used entities.
Let us see the important concepts of Object Oriented Design:
- Objects - All entities included in the solution design are known as objects. For example, person, banks, industry and customers are treated as objects. Every entity has some attributes linked to it and has some methods to perform on the attributes.
- Classes - A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object. In the solution design, attributes are saved as variables and functionalities are defined by use of methods or procedures.
- Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are wrapped together is called encapsulation. Encapsulation not only wraps important information of an object together, but also binds access of the data and methods from the outside world. This is called information hiding.
- Inheritance - OOD allows similar classes to heap (stack) up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it simpler to define specific class and to create generalized classes from particular ones.
- Polymorphism - OOD languages provide a tool where methods performing similar tasks but vary in arguments, can be given same name. This is called polymorphism, which allows a single interface performing tasks of different types. Depending upon how the function is called, respective portion of the code gets executed.
Key takeaway:
- Object oriented design deals around the entities and their properties instead of functions involved in the software system.
- This design pattern focuses on entities and its properties.
- The whole concept of software solution revolves around the used entities.
While doing detailed design the pseudo code description of the functions and the different data structures are created for the modules of the structured chart. These are marked out in the form of module specifications (MSPEC). Structured English is used in MSPEC. The MSPEC for leaf level modules should be described in algorithmic form and non-leaf modules tells the different ways in which responsibilities are authorized to lower level modules. DFD’s and SRS’s are referred to determine the functionality of the module.
Design is the specification of all major system components' internal elements, their properties, relationships, processing, and sometimes their algorithms and structures of data.
The detailed design can contain:
- Decomposition into programme units of major system elements.
- Allocation to divisions with organisational obligations.
- Interfaces for users
- States of Units and State Transitions
- Interaction of data and control between units
- Packaging and implementation of data, including issues of scope and visibility of elements of the software
- Data structures and algorithms
Key takeaway:
The process of refining and extending a system or component's preliminary design to the degree that the design is sufficiently complete for implementation to begin.
Design Verification is a method to confirm if the output of a designed software
product meets the input specifications by examining and providing evidence. The
goal of the design verification process during software development is ensuring that
the designed software product is the same as specified.
Design input is any physical and performance requirement that is used as the basis
for designing purpose.
Design output is the result of each design phase and at the end of total design effort.
The final design output is a basis for device master record.
Design Verification Process
Identification and preparation: During the development stage of a specification, the identification of verification activity is done in parallel. This enables the designer to make sure that the specification is verifiable. So a test engineer can start detailed test plan and procedures. Any changes in the specification should be communicated.
- Identifying the best approach to conduct verification, define measurement methods, required resources, tools, and facilities.
- The completed verification plan will be reviewed with the design team to identify issues before finalizing the plan.
Planning: Planning for verification is a concurrent activity with core and development teams. This occurs throughout the project life cycle. This will be updated as and when any changes are made to design inputs.
- During this phase, the software or system under test shall be documented in Scope.
- Preliminary test plan and test plan refinement are made at this stage. Test plan captures the critical milestone reducing the project risk.
- Tools, test environment, development strategy and identifying the requirements through inspection or analysis.
Developing: The test case development will coincide with SDLC methodology
implemented by a project team. A variety of test methods are identified during this
- stage.
- The design inputs must be developed including simplest verification activities which are unambiguous and verifiable.
- Verification time shall be reduced when similar concepts are conducted in
sequence. Even the output of one test can be used as input for subsequent tests.
- Tractability links are created between test cases and corresponding design inputs, to ensure that all the requirements are tested and the design output meets the design inputs.
Execution: The test procedures created during the development phase is executed
in accordance with the test plan, strictly following them in verification activity.
- If any invalid results occur or if any procedures required modification, it is important to document the changes and get proper approval.
- Any issues are identified and logged as a defect at this stage.
- Tractability matrix is created to verify that all the design input identified in the verification test plan has been tested and determine the pass ratio.
Reports: This activity is performed at the end of each phase of verification
Execution.
- The design verification report gives the detailed summary of verification results which includes the configuration management, test results for each type of testing and issues found during the verification activity.
- Design verification traceability report is created between requirements and corresponding test results to verify all the requirements have been tested and provided with appropriate results.
- Any non-conformance will be documented and appropriately addressed.
- Reviews are done upon the completion of design verification activity and are approved respectively.
Key takeaway:
- Design Verification is a method to confirm if the output of a designed software
product meets the input specifications by examining and providing evidence.
- The goal of the design verification process during software development is ensuring that the designed software product is the same as specified.
A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many others
uses.
Within the software development process, many metrics are that are all connected.
Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement Classification of Software Metrics
1. Product Metrics: These are the measures of various characteristics of the
software product. The two important software characteristics are:
- Size and complexity of software.
- Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the
software development process. For example, the efficiency of fault detection. They
are used to measure the characteristics of methods, techniques, and tools that are
used for developing software.
Types of Metrics
- Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
- External metrics: External metrics are the metrics used for measuring properties that are viewed to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
- Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to
check the project’s progress. Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as a base of new software. These metrics are used to decrease the development costs, time efforts and risks. The project quality can also be improved. As quality improves, the number of errors and time, as well as cost required, is also reduced.
Key takeaway:
- A software metric is a measure of software characteristics which are measurable or countable.
- Software metrics are similar to the four functions of management: Planning,
- Organization, Control, or Improvement.
- Within the software development process, many metrics are that are all connected.
References:
- Fundamentals of Software Engineering – Rajib Mall (3rd Edition) (PHI)
2. Software Engineering by Jan Sommerville (9th Edition) Pearson
3. Software Engineering Fundamentals –Behforooz & Hudson (Oxford: Indian Edition 1st)
