Problem:
Do you design software when you “write” a program? What makes software design different from coding?
Answer:
Design software
No, writing a program is the different concept in design software. Design is the place where software quality is established. Before starting of design software, first requirements should be analyzed and specified.
In the software design process, design engineering is the one of the concept. While beginning software, requirements have been analyzed and modeled. This model can be accessed for quality and improved before code is generated.
In a software engineering context, first need to develop the models of program. Not the program themselves.
Software design different from coding:
At first it is very clear that, design is not coding and coding is not design. It is created from program components.
Design is the description of the logic, which is used in solving the problem. Coding is the language specification which is implementation of the design. It runs on the computer and, provides the expected result.
Problem:
If a software design is not a program (and it isn’t), then what is it?
Answer:
Yes, software design is not a program. Coding or programming is a language which is used to represent the design. Programming is not good for representing details of architecture, components or their collaborations.
Software design contains a set of principles, concepts, and practices which leads to development of high quality product. Design plays an important role in the development of a successful software product.
The main aim of design is to create a model that presents firmness, commodity, and delight to customers those who use it. Software engineering continuously changes with new methods for better analysis and to evolve broader understanding.
Software design is like a kernel of software engineering. Software design is an action with the software engineering modelling activity, followed by code generation and testing.
The following are design methods which are implemented in software engineering:
• Object/Class design
• Architectural design
• Interface design
• Component design
Problem:
How do we assess the quality of a software design?
Answer:
The quality of software is assessed based on the design even before it is implemented. During design, the quality is assessed by conducting a series of technical reviews.
The following are the guidelines to assess the quality of the software design:
• A design should be simple created by using recognizable patterns which are easier for implementation and testing.
• A design should be modular that is, it can be broken down into smaller sub systems.
• A design should lead to data structures, components, and interfaces that are appropriate for classes and in turn reduce the complexity of connection with the external environment.
• A design is derived using repeatable methods and should be represented using simple notations which communicates its meaning.
The following are the FURPS quality attributes which are like a benchmark for a quality software design:
• Functionality
• Usability
• Reliability
• Performance
• Supportability
Problem:
Examine the task set presented for design. Where is quality assessed within the task set? How is this accomplished? How are the quality attributes discussed in Section 12.2.1 achieved?
Answer:
4633-8-4P SA: 4475
SR: 6376
Generic task set for design:
1. Examine information domain model and design appropriate data structures for data objects and their attributes
2. Select an architectural pattern appropriate to the software based on the analysis model
3. Partition the analysis model into design subsystems and allocate these subsystems within the architecture
4. Create a set of design classes or components
5. Design any interface required with external systems or devices
6. Design the user interface
7. Conduct component level design
8. Develop a deployment model
Quality is assessed for each element of the design model--data design, architecture, user interface, and component-level design
During design, assessing quality is accomplished by conducting a series of technical reviews (TRs). A technical review is a meeting conducted by members of the software team
Quality Attributes :
Quality Attributes represent a target for all software design. Set of attributes are represented as an acronym FURPS.
F – Functionality
U – Usability
R – Reliability
P – Performance
S – Supportability
These quality attributes can be achieved when these attributes are addressed before a design commences, but not after the design is complete and construction has begun.
Problem:
Provide examples of three data abstractions and the procedural abstractions that can be used to manipulate them.
Answer:
Data abstractions: It is the process of representing essential details not including internal details.
Examples:
1) First example of data abstraction is to abstract “Doors” as a data structure with essential properties:
Door: Properties
Type
Swing direction,
Manufacturer,
Insets,
Lights,
Weight,
Opening / Close mechanisms
2) Second example of data abstraction is “ College ”
College: Computer science,
Electrical Engineering
.
.
.
.
Mechanical Engineering
3) Third example of data abstraction is “ Software company:
Company: Software Architect
Software Manager
Sr. Developers
Jr. Developers
Tester
Procedural abstractions: The Procedural abstraction is to decompose problem to many simple sub works.
Examples:
1) Credit Card: Validate(User name, Password)
Check limited (Withdrawal limit)
2) Website: Add page(linking new page to home page)
Access (setting access permissions)
3) Online Medical transitions : patient list
Cost (Medical Lab bills)
" " Problem:
Describe software architecture in your own words.
Answer:
The software architecture is the structures of program components / modules. And
Software architecture is:
• An overall view of the solution to a problem
• The high-level design of modular components and how they interact
• A foundation that one can build on to solve a problem (e.g., rules, policies, attributes, etc.)
• An efficient method to meet a fixed set of well-defined attributes
Architecture needs to include:
architecture: The architectural vision, style, principle, key communication and control mechanisms and concepts that guide the team of architects in the creation of the architecture.
Architectural patterns: Structural patterns such as layers and client/server and mechanisms such as brokers and bridges.
Architectural views: Structural views help document and communicate the architecture in terms of the components and their relationships and are useful in assessing architectural qualities like extensibility and behavioral views are useful in thinking through how the components interact to accomplish their assigned responsibilities and evaluating the impact of what if scenarios on the architecture. Behavioral views are especially useful in assessing run time qualities such as performance and security. Execution views help in evaluating physical distribution options and documenting decisions.
Component specification: components are identified and assigned responsibilities that client components access through "contracted" interfaces. Component interconnections specify communication and control mechanisms and allow component interactions to accomplish system behavior. And key architectural design principles including abstraction, separation of concerns, postponing decisions, and simplicity, and related techniques such as interface hiding and encapsulation, as well as system decomposition principles and good interface design.
Problem:
Suggest a design pattern that you encounter in a category of everyday things (e.g., consumer electronics, automobiles, appliances). Briefly describe the pattern.
Answer:
4633-8-7P SA: 4478
SR: 6376
Consider a pattern named, IntermittentWindshieldWiper capability in an automobile industry.
Pattern name: Intermittent Wind Shield Wiper
Intent: It allows the driver to cause the windshield wipers to operate intermittently, with intermittent timing defined using a time-setting device such as a ring-dial on the wiper control arm.
Motivation: There are many situations in which precipitation is significant enough to warrant removal from the windshield, but not heavy enough to warrant continuous wiper operation.
Applicability: Integrated into all luxury automobiles and other automobiles that provide the feature as an option
Structure: wiper control arm, timer, and wiper actuator.
Participant’s- wiper control arm: turn on; turn off, set wiper speed, set timing level
Collaborations: wiper control arm defines the attributes of the control that are used by the driver; timer implements a clocking function that collaborates with timing control set using wipercontrolarm;
Wiper actuator sends control signals to the servomechanism the controls the wiper motor.
Consequences: The primary design force is the number of wiper timing levels and /or whether the timing level can be set on a continuous scale.
Problem:
Describe separation of concerns in your own words. Is there a case when a “divide and conquer” strategy may not be appropriate? How might such a case affect the argument for modularity?
Answer:
4633-8-8P SA: 4475
SR: 6376
Separation of concerns:
Separation of Concerns is a design concept. It refers to the delineation and correlation of software elements to achieve order within a system. That means a large and difficult problem can be divided into small parts and can be done easily. By dividing the work into parts and handling it, the effort decreases. By this we can handle complex problem more easily through proper separation of concerns. So complexity becomes manageable.
Yes, there is a case when a divide-and-conquer strategy may not be appropriate. The strategy may not be appropriate in the case where, the complexity when two problems are combined is greater than the sum of perceived complexity when each is taken separately. The argument for modularity is that, if you subdivide software indefinitely the effort required to develop it will become negligibly small. But in these types of cases, as the number of modules grows, the effort (cost) associated with integrating the modules grow. Hence the argument for modularity will not be appropriate.
Problem:
When should a modular design be implemented as monolithic software? How can this be accomplished? Is performance the only justification for implementation of monolithic software?
Answer:
To accomplish this, implement all the task performed by the software in a single module.
Maintenance cost is the other factor to implement it as a monolithic software. Maintenance cost of a modular software is greater than monolithic software. Thus, when there are very large number of modules of small size, then it should be implemented a monolithic software
Problem:
Discuss the relationship between the concept of information hiding as an attribute of effective modularity and the concept of module independence.
Answer:
592-9-10P SA Code: 4478
SR Code: 4578
Information hiding can be related to both coupling and cohesion. By limiting the availability the information to only those modules that have absolute need, coupling between modules is inherently reduced. Isolation of information predicates isolation of function, therefore cohesion of individual modules can also be improved.
Software architecture and design patterns embody modularity; that is, software is divided into separately named and addressable components, sometimes called modules that are integrated to satisfy problem requirements.
Monolithic software (large program composed of a single module) cannot be easily grasped by a software engineer. The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible.
It is the compartmentalization of data and function. It is easier to solve a complex problem when you break it into manageable pieces. “Divide-and-conquer”
Don’t over-modularize. The simplicity of each small module will be overshadowed by the complexity of integration “Cost”.
Modules should be specified and design so that information (algorithm and data) contained within a module is inaccessible to other modules that have no need for such information.
Hiding implies that effective modularity can be achieved by defining by a set of independent modules that communicate with one another only that information necessary to achieve software function.
The use of Information Hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later, during software maintenance. Because most data and procedures are hidden from other parts of the software, inadvertent errors introduced during modifications are less likely to propagate to other location within the software.
Problem:
How are the concepts of coupling and software portability related? Provide examples to support your discussion.
Answer:
The concept of coupling and software portability are interrelated like External world complier and operating systems coupling. Coupling is the concept, which is together with the reliability and strength among all relationships between functional units. As well as concept of software portability is usability of same components in different environments.
In the concept of optimal software, coupling has to be minimized and portability has to be maximized. Strong software, which contains low levels of coupling could easily and efficiently is portable. As the same way, if the software is portable it is probably due to the low levels of coupling which it has.
Example: Software portability adversely.
Consider a program that has been design to make use of special graphics features of an intelligent display. If the software is moved to a system without this type of display, major design and code modification may be required.
For this external coupling occurs when a component communicates or collaborates with infrastructure components like operation system functions, database capability, telecommunication functions. It should be limited to a small number of components or classes within a system. Software must communicate internally and externally.
Therefore, coupling is a fact of life and the designer should work to reduce coupling whenever possible and understand the ramifications of high coupling when it cannot be avoided.
" Problem:
Apply a “stepwise refinement approach” to develop three different levels of procedural abstractions for one or more of the following programs: (1) Develop a check writer that, given a numeric dollar amount, will print the amount in words normally required on a check. (2) Iteratively solve for the roots of a transcendental equation. (3) Develop a simple task-scheduling algorithm for an operating system.
Answer:
592-9-12P SA Code: 4478
SR Code: 4578
To create a functional hierarchy and as a result refine the problem. For example, considering the check writer, we might write:
Refinement 1:
Write dollar amount in words
Refinement 2:
Procedure write amount;
Validate amount is within bounds;
Parse to determine each dollar unit;
Generate alpha representation;
End write_amount
Refinement 3:
Procedure write_amount;
do while checks remain to be printed
if dollar amount > upper amount bound
then print "amount too large error message;
else set process flag true;
endif;
Determine maximum significant digit;
do while (process flag true and significant digits remain)
set for corresponded alpha phrase;
Divide to determine whole number value;
Concatenate partial alpha string;
Reduce significant digit count by one;
enddo
print alpha string;
enddo
end write_amount
Problem:
Consider the software required to implement a full navigation capability (using GPS) in a mobile, handheld communication device. Describe two or three crosscutting concerns that would be present. Discuss how you would represent one of these concerns as an aspect.
Answer: Problem:
Does “refactoring” mean that you modify the entire design iteratively? If not, what does it mean?
Answer:
4633-8-14P SA: 9420
SR: 6376
No, refactoring does not mean modifying the entire design iteratively. Refactoring is the process of changing a software system in such a way that it does not modify the external behavior of the code (design) yet improves its internal structure.
Problem:
Discuss what the dependency inversion principle is in your own words.
Answer:
Problem:
Why is design for testing so important?
Answer:
Design for test approach says the design will come first and the code is developed such that seams or test hooks can be inserted. Seams are locations in the design where code can be tested for the status of running software. It involves isolating the code to be tested from the production environment and testing it in a controlled one.
Design for test is important because:-
• Since testing is done at various seams, defects can be found out earlier.
• Test cases interrogate and control the running system.
• Testing at hooks also results in rectification of errors in code before they snowball.
• It results in long term maintenance of the system.
• Test are accountable and designing them makes testing exhaustive and extensive.
Problem:
Briefly describe each of the four elements of the design model.
Answer:
4633-8-15P SA: 9420
SR: 6376
The design model has four major elements:
1. Data design elements
2. Architectural design elements
3. Interface design elements
4. Component level design elements
Data design elements:
The data design (sometimes referred to as data architecting) creates a model of data and /or information that is represented at high level of abstraction (the customer/user’s view of data).
The structure of data has always been an important part of software design.
• At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications.
• At the application level, the translation of a data model into a database is crucial in achieving the business objectives of a system.
• At the business level, the collection of information stored in different databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself.
In every case, data design plays an important role.
Architectural design elements:
The architectural design elements provide an overall view of the software product.
It’s derived from three sources:
1. Information about the application domain for the software to be built.
2. Specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand; and
3. The availability of architectural styles and patterns.
The architectural design element is usually represented as a set of interconnected subsystems, often derived from analysis packages within the requirements model. Each subsystem may have its own architecture
Interface design elements:
The interface design elements of software show information flows into and out of the system and how it is communicated among the components defined as part of the architecture.
There are three important elements of interface design:
1. User interface (UI) – UI design is a major software engineering action. UI is a unique subsystem within the overall application architecture.
2. External interfaces to other systems, devices, networks, or other producers or consumers of information – the design of the external interfaces requires definitive information about the entity to which information is sent or received. It should incorporate error checking and appropriate security features.
3. Internal interfaces between various designs components – the design of internal interfaces is closely aligned with component level design.
These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.
Component-level design elements:
The component-level design elements describe the internal detail of each software component.
To accomplish this, the component-level design defines
• Data structures for all local data objects.
• Algorithmic detail for all processing that occurs within a component and
• An interface that allows access to all component operations.
The design details of a component can be modeled at many different levels of abstraction.
Solutions Chapter 12: DESIGN CONCEPTS
12.1) Yes, but the design is conducted implicitly — often in a haphazard manner. During design we develop representations of programs—not the programs themselves.
12.2) The intent of software design is to apply a set of principles, concepts, and practices that lead to the development of a high quality system or product. The goal of design is to create a model of software that will implement all customer requirements correctly and bring delight to those who use it.
12.3) Quality is assessed by conducting a series of formal technical reviews (FTRs). A FTR is a meeting conducted by members of the software team. Usually 2, 3 or 4 people participate depending on the scope of the design information to be reviewed. Each person plays a role: the review leader plans the meeting, sets an agenda, and the runs the meeting; the recorder takes notes so that nothing is missed, the producer is the person whose work product (e.g., the design of a software component) is being reviewed. At the end the team decides future action to the final product.
12.4) To develop a complete design model, the software team develops each element of the model iteratively. Each iteration provides additional detail and refinement. In addition, the design tasks applied for one project may differ from those applied to another project. The team must adapt a generic task set to meet the needs of the product, the people, and the project. Quality is assessed within the task set in the Component level design where the errors are corrected. The task set is given in the chapter.
12.5) Answers will vary
12.6) Software Architecture is the structure or organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components. In a broader sense, however, components can be generalized to represent major system elements and their interactions.
12.7) Answers will vary
12.8) Separation of concerns involves solving a complex problem by breaking it up into separately solved subproblems. There are cases in which different parts of a problem are interrelated in a manner that makes separate considerations more complex than combined considerations. Highly coupled problems exhibit this characteristic. However, continuing combination of problem parts cannot go on indefinitely because the amount of information exceeds one's ability to understand. Therefore, when (9.2) is not true, modularity may be modified, but not eliminated
12.9) In some time critical applications, monolithic implementation may be required. However, design can and should occur as if the software was to be implemented modularly. Then "modules" are coded in-line.
12.10) Information hiding can be related to both coupling and cohesion concepts. By limiting the availability of information to only those modules that have absolute need, coupling between modules is inherently reduced. In general, isolation of information predicates isolation of function; therefore, cohesion of individual modules can also be improved
12.11) External world, compiler, and operating system coupling will affect software portability adversely. As an example, consider a program that has been designed to make use of special graphics features of an intelligent terminal. If the software is moved to a system without the terminal, major design and code modifications may be required
12.12) We create a functional hierarchy and as a result refine the problem. For example, considering the check writer, we might write:
Refinement 1:
Write dollar amount in words
Refinement 2:
Procedure write amount;
Validate amount is within bounds;
Parse to determine each dollar unit;
Generate alpha representation;
end write_amount
Refinement 3:
procedure write_amount;
do while checks remain to be printed
if dollar amount > upper amount bound
then print "amount too large error
message;
else set process flag true;
endif;
determine maximum significant digit;
do while (process flag true and
significant digits remain)
set for corresponded alpha phrase;
divide to determine whole number
value;
concatenate partial alpha string;
reduce significant digit count by one;
enddo
print alpha string;
enddo
end write_amount
12.13) Answers will vary
12.14) No, refactoring is the process of improving the internal quality of a software product without changing its function or external behavior. It may be done to improve the processing speed of one of its functions or make one of its components easier to reuse in another system.
12.15) Dependency Inversion Principle says the high level code should not depend on detailed knowledge of supporting modules, the high level code should treat the lower level code as a black box.
12.16) A designer must give thought to the tests that will be conducted to exercise the component. The designer needs to provide appropriate test affordances—factoring the design in a way that lets test code interrogate and control the running system.
12.17) The four elements of the design model:
- Data/Class design - created by transforming the analysis model class-based elements into classes and data structures required to implement the software
- Architectural design - defines the relationships among the major structural elements of the software,
- Interface design - describes how the software elements, hardware elements, and end-users communicate with one another
- Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components