Unit 4
Design Engineering
Design Concepts
Software design is situated in the software engineering technical kernel and is implemented regardless of the model of the software process that is used. In the modeling activity, software design is the last software engineering action and sets the stage for construction (code generation and testing).
Each of the requirements model's components provides information that is necessary to construct the four design models needed for a complete design specification.
Fig 1: Flow of design model
The design role is fed by the requirements model, which is manifested by scenario-based, class-based, flow-oriented, and behavioural components.
The data/class design converts class models into realizations of the design class and the necessary data structures required for the program to be implemented. The basis for the data design action is given by the objects and relationships described in the CRC diagram and the detailed data content expressed by class attributes and other notations.
The architectural design describes the interaction between the software's key structural elements, the architectural styles and design patterns that can be used to fulfill the system's specified specifications, and the restrictions that influence the way architecture can be implemented.
The architecture of the Interface defines how the program interacts with, and with humans that use, systems that interact with it. An interface means a flow of information and a particular type of action (e.g., data and/or control). Usage scenarios and behavioural models, therefore, provide most of the data needed for the design of interfaces.
The component-level design converts software architecture structural elements into a procedural description of components of the software. The basis for component design is knowledge obtained from class-based models, flow models, and behavioural models.
You make decisions during design that eventually influence the success of software creation and, as importantly, the ease with which software can be maintained.
Design is the position where excellence in software engineering is promoted.
- Software design is the last software engineering action and sets the stage for code generation and testing.
- The software development design process deals with modifying the requirements of the client.
- In software engineering, architecture is the position where quality is fostered.
- You risk constructing an unpredictable scheme without specification.
The design of the software is an iterative process by which specifications are converted into a "blueprint" for software construction. That is, at a high level of abstraction the architecture is expressed, a level that can be traced to the basic purpose of the system and more comprehensive details, functional and behavioural specifications.
Subsequent refinement contributes to design representations at far lower levels of abstraction as design iterations occur. These can still be traced to specifications, but more subtle is the relation.
- The design provides you with software representations that can be tested for consistency.
- Design is the position where excellence in software engineering is promoted.
With a series of technical reviews, the consistency of the emerging design is evaluated in the design process. The three attributes that serve as a guide to the assessment of a successful design:
● All specific requirements found in the requirements model must be enforced by the design and all implied requirements desired by the stakeholders must be accommodated.
● For those who generate code and for those who evaluate and subsequently help the program, the design must be a readable, understandable guide for
● The design should provide a full picture of the program, addressing the details, functional, and behavioural domains from an implementation perspective.
Quality Guidelines - The software, to determine the consistency of a design representation, Technical standards for good design must be set by the team. The guidelines are the following:
2. Architecture should be modular, that is, logically partitioning the program into elements or subsystems.
3. Separate representations of data, architecture, interfaces, and components should be included in a design.
4. A design can lead to data structures that are ideal for the implementation of the classes and are derived from recognizable data patterns.
5. A layout can lead to elements that exhibit distinct functional features.
6. A design can lead to interfaces that reduce the complexity of ties with the external world and between components.
Quality Attribute - A collection of software quality attributes has been developed by Hewlett-Packard, FURPS-functionality, accessibility, reliability, efficiency, and supportability, provided the acronym.
For all software design, the FURPS quality attributes reflect an objective:
Key takeaway :
- With a series of technical reviews, the consistency of the emerging design is evaluated in the design process.
- Quality software refers to software that is reasonably free of bugs or defects, is delivered on time and within the budget stated, meets specifications and/or demands, and is maintainable
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.
Key takeaway :
- A design pattern defines a design framework that addresses a specific design problem within a particular context and amid "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.
4.4.1 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 set, 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 procedural abstraction, but precise specifics are suppressed. Data abstraction is a set of named data representing a data object.
Key takeaway :
- A procedural abstraction relates to a set of instructions that have a particular and restricted purpose.
4.4.2 Architecture
The architecture of the software alludes to "the general layout of the software and
How the context provides a structure with logical integrity”.
Architecture is, in its simplest form, the arrangement or organization of software components (modules), how 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 systems 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.
Key takeaway :
- Architecture is, in its simplest form, the arrangement or organization of software components (modules), how these components communicate, and the data structure used by the components.
4.4.3 Design Patterns
A pattern is a so-called insight nugget that transmits the essence of a known in a certain context, amid 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 amid "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
2. If they can reuse the pattern (hence, saving design time)
3. If the model may serve as a guide to creating a pattern that is similar, but functionally or structurally different.
Key takeaway :
- A design model systematically names, motivates, and demonstrates a general design that solves a recurring design issue in object-oriented systems.
4.4.4 Separation of Concerns
Separation of concerns is a principle of design that 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.
Key takeaway :
- Separation of concerns is a principle of design which implies that if it is subdivided into pieces that can each be solved.
4.4.5 Modularity
The most common manifestation of separation of worries is modularity.
Software is split into separately named and addressable components that are combined to fulfill problem requirements also called modules.
Modularity is the single attribute of software that enables a program 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 program.
Key takeaway :
- Modularity is the single attribute of software that enables a program to be intellectually manageable.
- You should split the design into several modules.
Fig 2: Modularity
4.4.6 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 is 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.
Key takeaway :
- Hiding information implies that modules are "Characterized by design decisions that hide from everyone else.
- Perhaps the most significant intellectual method built to help software design is knowledge hiding.
- Provides the fundamental inspiration for languages of the abstract data form (ADT)
4.4.7 Functional Independence
The idea of functional independence is a direct outgrowth of 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 program 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 program. 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, the 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.
Key takeaway :
- The idea of functional independence is a direct outgrowth of Separation of interests, modularity, and the principles of hiding knowledge and abstraction.
- Coupling relies on the complexity of the interface between modules
4.4.8 Refinement
Stepwise refinement is a technique for top-down design. The creation of 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.
Key takeaway :
- Stepwise refinement is a technique for top-down design.
- refinement is a process of elaboration that starts with a function statement or knowledge description at a high level of abstraction.
4.4.9 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, some of these problems span the entire structure and can not be easily compartmentalized.
4.4.10 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 the software is refactored. The effect would be software that is easier to integrate, easier to evaluate, and easier to manage.
4.4.11 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.
4.4.12 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 program execution.
System classes - System classes incorporate program 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:
Key takeaway :
- By supplying design information, a set of design classes refined the research class.
- You can identify a collection of design classes as the design model evolves.
As design activities are performed as part of the software process, the process component indicates the evolution of the design model. As each aspect of the analysis model is converted into a design equivalent and then iteratively refined, the abstraction dimension reflects the level of detail.
The dashed line shows the limit between the analysis and the models of architecture. The model of research slowly blends into the template and it is less apparent to provide a strong distinction.
The concept model components use UML diagrams that have been used in the research model. The difference is that, as part of the design, these diagrams are refined and elaborated; more implementation-specific specifics are given, and architectural layout and style, components within the architecture, and interfaces between the components and the outside are provided. Much of the world is highlighted.
Fig 3: Dimension of the design model
However, you should remember those model elements displayed along the horizontal axis are not always sequentially created. When the
the concept has been fully developed, the implementation model is typically delayed.
Key takeaway :
- The concept model components use UML diagrams that have been used in the research model.
- As design activities are performed as part of the software process, the process component indicates the evolution of the design model.
Like other things in software engineering, data design (sometimes referred to as data architecture) generates a data and/or knowledge model that is Described at a high abstract level. This data model is then refined into more and more implementation-specific representations that the computer-based system can process.
A significant part of software design has always been the structure of data. For the development of high-quality applications, the design of data structures and the associated algorithms needed to manipulate them is important at the software component level. At the application stage, the transformation into a database of a data model is central to the achievement of a system's business objectives.
The compilation of information collected in various databases and reorganized into a "data warehouse" at the business level allows data mining or exploration of knowledge that can have an impact on the performance of the organization itself.
Key takeaway :
- A significant part of software design has always been the structure of data.
- This data model is then refined into more and more implementation
- specific representations that the computer-based system can process.
The design of the architecture for applications is the equivalent of the ground plan of a home. An overall view of the house is provided to us by the floor plan. Elements of architectural design offer us an overall view of the program.
The model of architecture is derived from three sources:
(1) the application domain details for the software which is to be built;
(2) basic criteria model elements for the problem at hand, such as data flow diagrams or groups of analysis, their relationships and collaborations; and
(3) availability of styles and patterns of architecture.
The element of architectural design is typically defined as a collection of interconnected subsystems. Each subsystem can have its architecture.
Key takeaway :
- Elements of architectural design offer us an overall view of the program.
- The element of architectural design is typically defined as a collection of interconnected subsystems.
- Each subsystem can have its architecture.
The user interface design is similar to a series of detailed sketches for a house's doors, windows, and external utilities. The Configuration of the Interface Software elements represents the flow of information into and out of the system and how it is transmitted between the components identified as part of the architecture.
Three essential elements of interface design are available:
These elements of the interface design allow the software to communicate externally and allow internal communication and cooperation between the components that populate the architecture of the software.
Definitive information about the organization to which information is sent or received is needed for the design of external interfaces. Internal interface design is closely associated with design at the component level.
Key takeaway :
- Internal interface design is closely associated with design at the component level.
The design of the component-level for applications is for each room in a building, the equivalent of a collection of detailed drawings (and specifications). The component-level software architecture thoroughly defines the internal specifics of each component of the software.
The component-level architecture specifies data structures for all local data objects and algorithmic information for all processing within a component and an interface that allows access to all component operations to achieve this (behaviors).
A part is represented in UML diagrammatic form in the sense of object-oriented software engineering.
Fig 4: component-level design
To represent processing logic, a UML operation diagram can be used. It is possible to depict detailed procedural flow for a variable using either pseudocode or some other diagrammatic type (e.g. flowchart or box diagram). The algorithmic framework complies with the guidelines for structured programming (i.e., a set of constrained procedural constructs).
Key takeaway :
- The component-level software architecture thoroughly defines the internal specifics of each component of the software.
An element of a WebApp is
- Content Design
- Functional Design
4.10.1 Content Design at the Component Level
4.10.2 Functional Design at the Component Level
Modern Web applications have increasingly advanced processing features that—
You can design and develop WebApp functional components that are identical to software components for traditional software to achieve these (and many other) capabilities.
Key takeaway :
- Elements of WebApps:
- Content Design
- Functional Design
- At the component level, the formality of content design should be tuned to the characteristics of the WebApp to be constructed.
- Design and develop WebApp functional components that are identical to software components for traditional software.
Deployment-level design elements show how the physical computing environment that will help the program will assign software features and subsystems.
Fig 5: UML Development diagram
A UML deployment diagram is developed during the design and then refined. The diagram shown is in descriptor form. This implies that the deployment diagram displays the computing environment, but does not define configuration information directly.
Key takeaway :
- A UML deployment diagram is developed during the design and then refined.
- Deployment-level design elements show how the physical computing environment that will help the program will assign software features.
Many different qualities come to mind when you consider the architecture of a house. You are speaking about the general form of the physical structure at the most basic level. However, architecture is much more than that.
But architecture is still " thousands of decisions, both big and small " Any of these choices are made in design early on and can have a significant influence on all other design behaviour.
The device structure or structure that includes software components, the externally observable properties of those components, and the relationship between them is the software architecture of a program or computing system.
Architecture acts as a framework blueprint. It provides an abstraction for managing the complexities of the system and establishing a process of communication and coordination between components.
To satisfy both technological and operational requirements, it describes a standardized approach while maximizing common quality attributes such as performance and protection.
4.12.1 What is Architecture
Software architecture must model a system's configuration and how data and procedural components function together with each other.
The device structure or frameworks containing the software components, the externally observable properties of those components, and the relationships between them, are the software architecture of a program or computer system.
The design is not operational software. Instead, it's a representation that allows you to
The role of "software components" in any architectural representation is emphasized by this definition
A software component can be anything as simple as a program module or object-oriented class in the sense of architectural design, but it can also be generalized to include databases and 'middleware' that allow clients and servers to configure a network. Component properties are those features that are important for an understanding of how the components interact with other components.
Internal properties (e.g., algorithm details) are not defined at the architectural level. Component relationships can be as basic as a procedure call from one module to another or as complex as a protocol for accessing a database.
4.12.2 Why is Architecture Important
Three key reasons for the value of software architecture:
★ Software architecture representations are an enabler for cooperation between all parties (stakeholders) involved in developing a computer-based framework.
★ The architecture highlights early design decisions that will have a profound influence on all the work that follows in software engineering and, as importantly, on the system's eventual performance as an operating organization.
★ A relatively small, intellectually understandable model of how the system is organized and how its components work together is architecture.'
Key takeaway :
- Architecture acts as a framework blueprint.
- Software architecture must model a system's configuration and how data and procedural components function together with each other.
- It provides an abstraction for managing the complexities of the system and establishing a process of communication and coordination between components.
- The architecture highlights early design decisions that will have a profound influence on all the work that follows in software engineering
Architectural style defines a type of system that covers
2. a collection of connectors that allow components to "communicate, coordinate and cooperate";
3. Restrictions that determine how to incorporate components to shape the system;
4. Semantic models allow a designer to comprehend a system's overall properties by analyzing the known properties of its parts.
An architectural style is a modification based on an entire system's architecture. The aim is to create a framework for all elements of the system.
An architectural pattern imposes a transformation on the nature of architecture, like an architectural theme. However, in a variety of fundamental ways, a pattern varies from a style:
● A pattern's reach is less broad, concentrating in its entirety on one aspect of the architecture rather than the architecture;
● A pattern imposes an architecture rule specifying how the program can manage some element of its infrastructure level functionality (e.g., concurrency).
● In the context of architecture, architectural trends seek to fix particular behavioural problems (e.g., how real-time applications handle synchronization or interrupt).
Patterns may be used to shape the overall structure of a system in accordance with an architectural design.
Key takeaway :
- An architectural style is a modification based on an entire system's architecture.
- The aim is to create a framework for all elements of the system
While over the past 60 years, millions of computer-based systems have been created, the vast majority can be classified into one of a relatively limited number of architectural styles:
Data-centered architectures - At the core of this architecture, a data store (e.g. a file or database) is located and is often accessed by other components that update, add, remove, or delete. Alternatively, alter data inside the shop.
A central repository is accessed by client applications. The data repository is, in some instances, passive.
That is, the data is accessed by client software irrespective of any modifications to the data or other client software's behaviour. Integrability is promoted by data-centered architectures. That is, it is possible to modify existing components and incorporate new client components to the architecture without thinking about other clients (because the client components operate independently).
Fig 6: Data centered architecture
Data-flow architectures - When input data is converted into output data via a set of computational or deceptive elements, this architecture is used. There is a series of components in a pipe-and-filter pattern, called filters, connected by pipes that relay data from one component to the next.
Each filter operates independently of those upstream and downstream components are designed to expect data input of a certain type and produce data output of a specified form (to the next filter).
Fig 7: Data flow architecture
Call and return architectures - This architectural style helps you to achieve a layout of the software which is relatively simple to alter and scale. Inside this, some substyles exist. The category:
● Main program/subprogram architecture - "This classic structure of the program decomposes the function into a hierarchy of control where a "key" program invokes some components of the program that Other components can also be invoked in turn.
● Remote procedure call architecture - Multiple computers on a network are spread around the components of a main program/subprogram architecture.
Fig 8: main program / subprogram architecture
Object-oriented architectures - Data and the operations that must be applied to modify the data are encapsulated by the components of a device. Via message passing, communication, and synchronization between components are achieved.
Layered architectures - Some different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing.
Intermediate layers provide utility services and application software functions. These architectural styles are only a small subset of those available.
Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural style and/or combination of patterns that best fits those characteristics and constraints can be chosen.
For example, a layered style (appropriate for most systems) can be combined with a data-centered architecture in many database applications
Fig 9: layered architecture
Key takeaway :
- A central repository is accessed by client applications. The data repository is, in some instances, passive
- This architectural style helps you to achieve a layout of the software which is relatively simple to alter and scale
- Intermediate layers provide utility services and application software functions
- architectural styles are only a small subset of those available.
References:
1.Ian Sommerville, ―Software Engineering‖, Addison and Wesley, ISBN 0-13-7035152
2.Pankaj Jalote, ―An Integrated Approach to Software Engineering‖, Springer, ISBN 13:9788173192715.
