Unit 3
Design Engineering
Software Process:
● The primary objective of design engineering is to create a model that demonstrates firmness, delight and commodity.
● The design of software is an iterative process in which specifications are converted into the software development blueprint.
Software Quality:
● Using identifiable architectural types, a design is developed and composes a successful design characteristic of components and is implemented for testing in an evolutionary way.
● A software design must be modular, so that the software must be logically separated into components.
● The representation of information, architecture, interface and components should be distinct in design.
● A template must have an acceptable data structure and identifiable patterns of data.
● Components of the design must display an individual functional element.
● A design provides an interface that reduces the complexity of the components' connections.
Quality Attributes -
Attributes such as 'FURPS' include the following:
Functionality:
It assesses the program's feature set and capabilities.
Usability:
Considering the variables such as human aspect, general aesthetics, accuracy and documentation, it is accessed.
Reliability:
It is calculated by parameters such as failure frequency and security, accuracy of the output result, mean-time-to-failure (MTTF), failure recovery and predictability of the software.
Performance:
It is calculated by considering the speed of processing, response time, use of energy, throughput and performance.
Supportability:
● It combines the capability, adaptability, and serviceability of the programme to expand. Maintainability is described by these three concepts.
● Testability, compatibility and configurability are the terminology used to easily install a device and easily discover the problem.
● More features such as compatibility, extensibility, fault tolerance, modularity, reusability, robustness, security, portability, scalability are also included in Supportability.
Key takeaways
- The design of software is an iterative process in which specifications are converted into the software development blueprint.
- The representation of information, architecture, interface and components should be distinct in design.
- The primary objective of design engineering is to create a model that demonstrates firmness, delight and commodity.
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.
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.
Key takeaways
A procedural abstraction relates to a set of instructions that have a particular and restricted purpose.
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 organization 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.
Key takeaways
Architecture is, in its simplest form, the arrangement or organization of software components (modules), the way in which these components communicate, and the data structure used by the components.
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
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 takeaways
A design model systematically names, motivates, and demonstrates a general design that solves a recurring design issue in object-oriented systems.
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.
Key takeaways
Separation of concerns is a principle of design which implies that if it is subdivided into pieces that can each be solved.
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.
Key takeaways
- Modularity is the single attribute of software that enables a programme to be intellectually manageable.
- You should split the design into several modules.
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.
Key takeaways
- 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)
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.
Key takeaways
- The idea of functional independence is a direct outgrowth Separation of interests, modularity, and the principles of hiding knowledge and abstraction.
- Coupling relies on the complexity of the interface between modules
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.
Key takeaways
- 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.
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 can not 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.
Key takeaways
- 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 1: dimension of the design model
However, you should remember that model elements displayed along the horizontal axis are not always sequentially created. When the
Concept has been fully developed; the implementation model is typically delayed.
Key takeaways
- 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.
A design pattern in software engineering is a typically repeatable approach to a frequently occurring software design problem. A design pattern is not a finished design that can be translated into code directly. In several different situations, it is a summary or blueprint for how to solve a problem that can be used.
Use of design patterns
By supplying tested, validated development paradigms, design patterns will speed up the development process. Effective design of software involves awareness of problems that might not become obvious until later in implementation. The reuse of design patterns helps avoid subtle problems that can cause serious problems and increases the readability of code for coders and architects familiar with the patterns.
People also only understand how to apply certain software design techniques to certain problems. It is difficult to apply these techniques to a wider variety of problems. Design patterns include general solutions, recorded in a manner that does not require detail linked to a particular problem.
Furthermore, trends encourage developers to communicate using well-known, well-known names for software interactions. It is possible to refine common design patterns over time, rendering them more durable than ad-hoc designs.
Patterns of software design, grouped into three classes on the basis of the plan to use them: creational, behavioral, or structural:
❏ Patterns of creation design are synonymous with the creation of objects and their purpose is to allow programmers to create software objects without really understanding what they create outside the interfaces themselves. In computer programming, known as knowledge hiding, there is a basic concept. As programmers code using interfaces for the development of structures and objects, they obey this basic concept well.
❏ Organizational groups are concerned with structural design trends. The patterns of structural design are static in nature; they are not expected to alter. Structural construction patterns include the adapter, the bridge, composite, decorator, facade, flyweight, and proxy, as set out by the Gang of Four.
❏ Behavioral design patterns are concerned with the program's runtime or dynamic system behaviour, which help describe the functions of software objects and their interactions. Behavioral patterns are meant to alter through their dynamic nature, and are not static and include very little structural code. The gang of four explains patterns of behavioural software design called the chain of responsibility, order, translator, mediator, memento, observer, state, strategy, prototype and visitor process.
Key takeaways
- A design pattern is not a finished design that can be translated into code directly.
- In several different situations, it is a summary or blueprint for how to solve a problem that can be used.
Architectural design is a method for defining the sub-systems that make up a system and the sub-system control and communication structure. A summary of the software architecture is the result of this design process. Architectural design is an early stage of the process of system design. It reflects the interaction between processes of specification and design and is often conducted in parallel with other activities of specification.
At two levels of abstraction, software architectures can be designed:
● The design of individual programs is concerned with small architecture. At this stage, we are concerned with the manner in which an individual programme is broken down into elements.
● In large architecture is concerned with the architecture of complex business systems, and other elements of systems, programs. These enterprise systems are spread over numerous computers that can be owned and operated by various businesses.
3.5.1 Design Decisions
Architectural design is a creative activity, so the process varies according to the type of structure being built. A number of common decisions, however, cover all design processes and these decisions influence the system's non-functional features:
● Is there an application architecture that can be used generically?
● To organize the method, what approach will be used?
● How will the scheme be broken down into modules?
● What technique for regulation should be used?
● How is the architectural plan going to be assessed?
● How should the design be documented?
● How's the system going to be distributed?
● What are suitable architectural styles?
Similar architectures also have structures in the same domain that represent domain concepts. Application product lines with variations that meet unique customer specifications are designed around a core architecture. A system's architecture can be built around one of several architectural patterns/styles, which capture an architecture's essence and can be instantiated in various ways.
The basic architectural style should rely upon the requirements of the non-functional system:
● Performance: Localize essential tasks and minimize experiences. Using components that are wide rather than fine-grain.
● Security: Using a layered system with vital resources in the inner layers.
● Safety: In a limited number of sub-systems, localize safety-critical functions.
● Availability: Redundant elements and fault tolerance mechanisms are included.
● Maintainability: Using replaceable, fine-grain parts.
3.5.2 Views
Only one view or viewpoint of the structure is shown by each architectural model. It could explain how a system is decomposed into modules, how the run-time processes communicate, or how system components are spread around a network in various ways. You typically need to present several views of the software architecture for both design and documentation.
View model of software architecture:
● A logical view that shows the main abstractions as objects or object classes in the method.
● A process view that explains how the system is composed of interacting processes at run-time.
● A development viewpoint, which explains how the programme is broken down for development.
● A physical view that illustrates the hardware of the device and how software components are spread through system processors.
3.5.3 Patterns
Patterns are a form of information representation, sharing and reuse. A stylized definition of a successful design method that has been tried and tested in various environments is an architectural pattern. Patterns should include data on when they are and when they are not helpful. Using tabular and graphical representations, patterns can be described.
3.5.4 Application Architectures
In order to satisfy an organizational need, application systems are developed. As organizations have a lot in common, their application systems often tend to have a common architecture that represents the specifications for the application. An architecture for a type of software system that can be configured and modified to build a system that meets particular specifications is a generic application architecture.
It is possible to use application architectures as:
● An architectural design starting point.
● Checklist for design.
● Way to coordinate the development team's work.
● Means of testing elements for reuse.
● Vocabulary to talk about forms of application.
Examples of application types:
Data processing applications
Data oriented applications that process data in batches during processing without explicit user interaction.
Transaction processing applications
Data-centric applications that process user requests in a system database and update details.
Event processing systems
Applications where device behaviour depend on the understanding of events from the environment of the scheme.
Language processing systems
Applications in which the intentions of the users are defined in a formal language which the system processes and interprets.
Key takeaways
- Architectural design is a creative activity, so the process varies according to the type of structure being built.
- A system's architecture can be built around one of several architectural patterns/styles, which capture an architecture's essence and can be instantiated in various ways.
- Architectural design is an early stage of the process of system design.
- A summary of the software architecture is the result of this design process.
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 in order to achieve this (behaviors).
A part is represented in UML diagrammatic form in the sense of object-oriented software engineering.
Fig 2: component level design
In order 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).
A part can have three distinct viewpoints: object-oriented view, conventional view, and process-related view.
Object-oriented view:
A part is seen as a set of one or more groups of co-operation. To define all attributes and operations that relate to its implementation, each problem domain class (analysis) and infrastructure class (design) are explained. It also includes the concept of interfaces that allow classes to interact and cooperate.
Conventional view:
It is seen as a functional element or a software module that incorporates the processing logic, the internal data structures necessary for the processing logic to be implemented, and an interface that allows the component to be invoked and data to be transferred to it.
Process-related view:
In this view, the framework builds from the existing components maintained in a library instead of building each component from scratch. Components are chosen from the library and used to populate the architecture as the software architecture is formulated.
● Grids, buttons referred to as controls, and utility modules are used in a user interface (UI) component to expose a particular subset of functions found in other components.
● Those that are resource-intensive, not regularly accessed, and must be enabled using the just-in-time (JIT) method are other common types of components.
● Many components, such as Enterprise JavaBean (EJB), .NET components, and CORBA components, are invisible and distributed in enterprise business applications and internet web applications.
Key takeaways
The component-level software architecture thoroughly defines the internal specifics of each component of the software.
As each S/W part is created, these concepts can be used to direct the designer.
➢ Open - closed principle (OCP): For extension, a module [component] should be open but closed for modification. The designer should define the component in a way that enables it to be expanded without the need for internal modifications to the component (code or logic-level).
➢ The Liskov Substitution Principle (LSP): The subclasses should be replaceable with their base classes. If a class derived from the base class is transferred to the component instead, a component that uses a base class can continue to operate properly.
➢ Dependency Inversion Principle (DIP): "Abstractions rely on it. "Do not rely on concretions." Abstractions are the place where, without great complications, a design can be expanded.
➢ The Interface Segregation Principle (ISP): Many interfaces unique to the client are better than one interface for general purposes. To represent each big category of customers, the designer should develop a customized design.
➢ The Release Reuse Equivalency Principle (REP): The reuse granule is the release granule." There is an implicit contract between the developer of the reusable entity and the individuals who will use it when classes or components are designed for reuse."
➢ The Common Closure Principle (CCP): "Together, classes that change belong together." Classes should be cohesively packaged. It is possible that only certain classes inside the package may need alteration if any characteristic of a region needs to change.
➢ The Common Reuse Principle (CRP): "Classes that are not reused should not be grouped together." The release number of the package changes when one or more classes with a package update.
❖ Component
For components that are defined as part of the architectural model and then refined and elaborated as part of the component-level model, naming conventions should be set up.
❖ Interface
Interfaces provide essential communication and collaboration knowledge (as well as helping us to achieve the OCP).
❖ Dependencies and inheritance
Modeling dependencies from left to right and inheritance from bottom (derived classes) to top is a good idea (base classes).
A crucial aspect of every software product is the user interface (UI). Users do not even consider it when it's done right. When it's done badly, consumers cannot get through it to use a product effectively.
Most designers follow interface design guidelines to improve the chances of success when designing user interfaces. The principles of interface design reflect high-level concepts which are used to direct software design. I'll share a few basic concepts in this post.
8 Golden User Interface Design Principles are a "rule" that needs to be taken into account in the design of the interface. On August 21, 1947, in his book entitled Designing the User Interface: Methods for Successful Human-Computer Interaction, Ben Schneiderman suggested this Golden Rule.
- Strive for consistency
For similar cases, creating' compatible interfaces' means using the same design patterns and the same sequences of actions. This involves, but is not limited to, the proper use of colour, typography, and terminology during your user journey through prompt screens, commands, and menus.
2. Enable Frequent Users to Use Shortcuts
Speaking of using UI rules as shortcuts, shortcuts can also help your users, especially if they often need to complete the same tasks.
Expert users can find the following characteristics helpful:
● Abbreviations
● Function keys
● Hidden commands
● Macro facilities
3. Offer informative feedback
There ought to be interface input for any user behaviour. The reaction should be modest for frequent and minor acts, while the response should be more substantial for infrequent and significant actions.
4. Design dialogs to yield closure
Sequences of acts with a beginning, middle, and end can be grouped into classes. At the end of a group of activities, insightful feedback gives users the pleasure of success, a feeling of relaxation, the signal to drop contingency plans from their minds, and an indication to prepare for the next group of actions. E-commerce websites, for instance, switch users from product collection to checkout, finishing with a simple confirmation page that completes the purchase.
5. Offer Simple Error Handling
To prevent errors to the greatest extent possible, a good interface should be built. But the system needs to make it easy for the user to grasp the problem and know how to fix it when mistakes do occur. Displaying straightforward error notices along with descriptive hints to fix the problem are easy ways to manage errors.
Error Prevention:
● Error prevention over error correction
● Automatic detection of errors
● Clear error notifications
● Hints for solving the problem
6. Permit easy reversal of actions
As users know that mistakes can be undone, this feature relieves uncertainty and facilitates exploration of unfamiliar choices. Reversibility units may be a single operation, a data-entry task, or a full collection of actions, such as a name-address block input.
7. Keep users in control
The feeling that they are in control of the interface and that the interface reacts to their behaviour is highly desired by seasoned users. They don't want surprises or changes in familiar actions, and are upset by repetitive sequences of data entry, difficulty obtaining the required details, and failure to achieve the desired outcome.
8. Reduce short-term memory load
The limited capacity of humans for short-term memory information retrieval (the rule of thumb is that individuals can recall "seven plus or minus two pieces" of information) allows designers to avoid interfaces where users need to remember information from one display and then use that information on another display. This means that the reentry of phone numbers should not be needed for mobile phones, website positions should remain accessible and long forms should be compacted to match a single display.
Key takeaways
- A clear interface can make it much easier for the customers to achieve their tasks and objectives.
- 8 Golden User Interface Design Principles are a "rule" that needs to be taken into account in the design of the interface.
- The principles of interface design reflect high-level concepts which are used to direct software design.
● The interface review is done once. It is important to define in detail all the tasks needed by the end user and the interface design activity begins.
● Like all other software engineering design processes, interface design is an iterative process.
● step in the design of the user interface happens multiple times. Each data produced in the previous step is elaborated and refined.
● However, so many models of user interface design have been suggested, all of which propose a combination of the following steps :
❏ Analysis, description of interface objects and action using knowledge generated during interface analysis (operation).
❏ Defines events that trigger a change in the state of the user interface.
❏ Show each state of the interface, as it will actually look at the end-user.
❏ Indicate how the user interprets the state of the systems through the interface from the information given.
Applying interface design steps -
Defining the interface artefacts and the acts that are applied to them are the most significant steps in interface design
● Cases of usage are parsed to satisfy this.
● That is, a description is written of a use case.
● To construct a list of objects and actions, nouns (objects) and verbs (actions) are separated.
● Once the objects and behaviour are iteratively described and elaborated, their forms are categorized.
Interface design issue -
- Response time
- Help facilities
- Error handling
- Menu and command labeling
- Application accessibility
- internationalization
Key takeaways
- Like other software engineering design processes, interface design is an iterative process.
- The interface review is done once.
- Each data produced in the previous step is elaborated and refined.
The assessment should be used in all phases of the process of design. Its main aim is to evaluate design efficiency, to assess how it suits users, to meet their needs.
The likelihood of developing a convincing user interface increases considerably after several series of revisions, drawings, wireframes, mockups, prototypes, meetings, brainstorming sessions with the stakeholders, end-users, and project team. Success knocks at the threshold.
A prototyping model is developed in the design assessment and turned over to the consumer to decide if it is developed according to the customer's requirements.
The end user is only able to test the product and verify that it meets the specifications.
After getting the user's input, the developed ones research it well and the feedback is real, then the developer makes the modification.
Fig 3: design evaluation cycle
Key takeaways
- The end user is only able to test the product and verify that it meets the specifications.
References
- Roger Pressman, “Software Engineering: A Practitioner’s Approach”, McGraw Hill, ISBN 0-07-337597-7
- Ian Sommerville, “Software Engineering”, Addison and Wesley, ISBN 0-13-7035152
- Joseph Phillips, “IT Project Management-On Track From start to Finish”, Tata McGraw-Hill, ISBN13:978-0-07106727-0, ISBN-10:0-07-106727-2
- Pankaj Jalote, “Software Engineering: A Precise Approach”, Wiley India, ISBN: 9788-1265-2311-5
- Marchewka, “Information Technology Project Management”, Willey India, ISBN: 9788-1265-4394-6
- Rajib Mall, “Fundamentals of Software Engineering”, Prentice Hall India, ISBN-13:9788-1203-4898-1
