1. Software Engineering Fall 2005
Lecture 7 Design Engineering Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman
Software Engineering
Fall 2005

2. Overview
A software design is a meaningful engineering representation of some software product that is to be built.
A design can be traced to the customer's requirements and can be assessed for quality against predefined criteria.
During the design process the software requirements model is transformed into design models that describe the details of the data structures, system architecture, interfaces, and components.
Each design product is reviewed for quality (i.e., identify and correct errors, inconsistencies, or omissions) before moving to the next software engineering action.

3. Design
Design creates a representation or model of the software, but unlike the analysis model (that focuses on describing required data, function and behavior), the design model provides detail about:
- software data structures,
- architecture,
- interfaces, and components that are necessary to implement the system.

4. Design Engineering
Encompasses the set of principles, concepts, and practices that lead to the development of a high quality system or product
Design concepts must be understood before the mechanics of design practice are applied
Goal of design engineering is to produce a model or representation that is bug free (firmness), suitable for its intended uses (commodity), and pleasurable to use (delight)

5. Design Engineering Steps
First, the architecture of the system or product must be represented.
Then, the interfaces that connect the software to end-users, to other systems and devices, and to its own constituent components are modeled.
Finally, the software components that are used to construct the system are designed.
Software engineers conduct each of the design tasks.

6. Work Product
A design model that encompasses architectural, interface, component-level, and deployment representations is the primary work product that is produced during software design.
The design model is assessed by the software team in an effort to determine whether it contains errors, inconsistencies, or omissions; whether better alternatives exist; and whether the model can be implemented within the constraints, schedule and cost that have been established.

7. 1. Design within the Context of Software Engineering
Software design sits at the kernel of software engineering and is applied regardless of the software process model that is used.
Beginning once software requirements have been analysed and modeled, software design is the last software engineering action within the modeling activity and sets the stage for code generation and testing.
The analysis model, manifested by scenario-based, class-based, flow-oriented and behavioral elements, feed the design task.

8. Design within the Context of Software Engineering
Using design notation and design methods discussed later, design produces:
- a data/class design
- an architectural design
- an interface design, and
- a component design

9. Analysis Model -> Design Model

10. Data/Class design
Created by transforming the analysis model class-based elements (class diagrams, analysis packages, CRC models, collaboration diagrams) into classes and data structures, required to implement the software
The classes and relationships defined by CRC index cards and the detailed data content depicted by class attributes and other notation provide the basis for the data design activity.
Part of class design may occur in conjunction with the design of software architecture.
More detailed class design occurs as each software component is designed.

11. Architectural Design
Defines the relationships among the major structural elements of the software
The architectural design representation – the framework of a computer-based system- can be derived from:
the system specification,
the analysis model,
and the interaction of subsystems defined within the class-based elements and flow-oriented elements (data flow diagrams, control flow diagrams, processing narratives) of the analysis model

12. Interface design
Describes how the software elements, hardware elements, and end-users communicate with one another
It is derived from the analysis model scenario-based elements (use-case text, use-case diagrams, activity diagrams, swimlane diagrams), flow-oriented elements, and behavioral elements (state diagrams, sequence diagrams)

13. Component-Level Design
Created by transforming the structural elements defined by the software architecture into a procedural description of the software components
Uses information obtained form the analysis model class-based elements, flow-oriented elements, and behavioral elements

14. 2. Design Quality A good design must :
implement all explicit requirements from the analysis model and accommodate all implicit requirements desired by the user
be readable and understandable guide for those who generate code, test components, or support the system
provide a complete picture (data, function, behavior) of the software from an implementation perspective

15. Quality Guidelines I A design should exhibit an architecture that:
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics; and
(3) can be implemented in an evolutionary fashion
For smaller systems, design can sometimes be developed linearly.
A design should be modular; that is, the software should be logically partitioned into elements or subsystems
A design should contain distinct representations of data, architecture, interfaces, and components.
A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.

16. Design Quality Guidelines II
A design should lead to components that exhibit independent functional characteristics.
A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.
A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
A design should be represented using a notation that effectively communicates its meaning.

17. Design Quality Attributes I
Functionality – is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system.
Usability - is assessed by considering human factors, overall aestethics, consistency, and documentation.

18. Design Quality Attributes II
Performance – is measured by processing speed, response time, resource consumption, throughput and efficiency.
Supportability – the ability to extend the program (extensibility), adaptibility, servicability.

19. Generic Design Task Set I
1. Examine the information 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, design interfaces, and allocate analysis functions (classes) to each subsystem
4. Create a set of design classes
- Translate analysis class into design class
- Check each class against design criteria and consider inheritance issues
- Define methods and messages for each design class
- Select design patterns for each design class or subsystem after considering alternatives
- Revise design classes and revise as needed

20. Generic Design Task Set II
5. Design any interface required with external systems or devices.
6. Design user interface
- Review task analyses
- Specify action sequences based on user scenarios
- Define interface objects and control mechanisms
- Review interface design and revise as needed
7. Conduct component level design
- Specify algorithms at low level of detail
- Refine interface of each component
- Define component level data structures
- Review components and correct all errors uncovered
8. Develop deployment model

21. Design Principles
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should “minimize the intellectual distance”
between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created, not after the fact.
The design should be reviewed to minimize conceptual (semantic) errors.

22. 3. Design Concepts
A set of fundamental software design concepts has evolved over the history of software engineering.
Each provides the software designer with a foundation from which more sophisticated design methods can be applied.

23. 3.1. Abstraction
Allows designers to focus on solving a problem without being concerned about irrelevant lower level details
At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided.

24. Procedural Abstraction
Refers to a sequence of instructions that have a specific and limited function.
The name of procedural abstraction implies these functions, but specific details are suppressed.
For example: The word Open, for a door, implies a long sequence of procedural steps (e.g. walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.).

25. Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter

26. Data Abstraction
A named collection of data that describes a data object.
For example: a data abstraction for door would encompass a set of attributes that describe the door (e.g. door type, swing direction, opening mechanism, weight, dimensions).
The procedural abstraction open would make use of information contained in the attributes of the information contained in the attributes of the data abstraction door.

27. Data Abstraction door manufacturer model number type swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure

28. 3.2. Architecture
Software architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system
In the simplest form, architecture is the structure or organisation of program components, the manner in which these components interact, and the structure of data that are used by the components.
In a broader sense, components can be generalised to represent major system elements and their interactions.

29. Architecture
The architectural design can be represented using one or more of a number of different models:
Structural models –represents architecture as an organised collection of program components.
Framework models – increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications.
Process models focus on the design of the business or technical process that the system must accommodate.
Functional models can be used to represent the functional hierarchy of a system.

30. 3.3. Patterns
Design patterns - description of a design structure that solves a particular design problem within a specific context and its impact when applied
The intent of each design pattern is to provide a description that enables a designer to determine:
If the pattern is applicable to the current work
If the pattern can be reused
If the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern

31. 3.4. Modularity
Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.
Modularity - the degree to which software can be understood by examining its components independently of one another

32. Modularity
What is the "right" number of modules for a specific software design?
It is easier to solve a complex problem when you break it into manageable pieces. – it is an argument for modularity.
However, as the number of modules grows, the effort (cost) associated with integrating modules also grows.
There is a number of modules that would result in minimum development cost, but we do not have the necessary sophistication to predict M with assurance.

33. Modularity module development cost cost of software module integration
optimal number
number of modules
of modules

34. Modularity We modularise a design (and the resulting program) so that:
Development can be more easily planned;
Software increments can be defined and delivered;
Changes can be more easily accommodated;
Testing and debugging can be conducted more efficiently;
And long-term maintenance can be conducted without serious side effect.

35. 3.5. Information Hiding
Modules should be specified and designed so that information (data and procedure) contained within a module is inaccessible to modules that have no need for such information
Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function.
Abstraction helps to define the procedural (or informational ) entities that make up the software.

36. Why Information Hiding?
Reduces the likelihood of “side effects”
Limits the global impact of local design decisions
Emphasizes communication through controlled interfaces
Discourages the use of global data
Leads to encapsulation - an attribute of high quality design
Results in higher quality software – 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 locations within the software.

37. 3.6. Functional Independence
Achieved by developing modules with ‘single-minded’ purpose and an aversion to excessive interaction with other models
We want to design software so that each module addresses a specific subfunction of requirements and has a simple interface when viewed from other parts of the program structure.

38. Why Functional Independence?
It is easier to develop independent modules, because function may be compartmentalised and interfaces are simplified.
Easier to maintain and test because: secondary effects caused by design or code modification are limited; error propagation is reduced; and reusable modules are possible.

39. Functional Independence
Assessed by:
Cohesion – an indication of the relative functional strength of a module.
Coupling – an indication of the relative interdependence among modules.

40. Cohesion
The degree to which module performs one and only one function.
A cohesive module performs a single task, requiring little interaction with other components in other parts of a program.
A cohesive module should (ideally) do just one thing.

41. Coupling
The degree to which module is ‘connected’ to other modules at the system.
Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

42. 3.7. Refinement
Process of elaboration where the designer provides successively more detail for each design component
It is actually a process of elaboration.
We begin with a statement that describes function or information conceptually, but provides no information about the internal workings of the function or the internal structure of the data.
Refinement causes the designer to elaborate on the original statement, providing more and more details as each successive refinement (elaboration) occurs.

43. Stepwise Refinement open walk to door; reach for knob; open door;
repeat until door opens
turn knob clockwise;
walk through;
if knob doesn't turn, then
close door.
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

44. Refinement Abstraction and refinement are complementary concepts.
Abstraction enables a designer to specify procedure and data and yet to suppress low-level details.
Refinement helps the designer to reveal low-level details as design progresses.
Both concepts aid the designer in creating a complete design model as the design evolves.

45. 3.8. Refactoring
Process of changing a software system in such a way internal structure is improved without altering the external behavior or code design
When software is refactored, the existing design is examined for
redundancy
unused design elements
inefficient or unnecessary algorithms
poorly constructed or inappropriate data structures
or any other design failure that can be corrected to yield a better design.

46. OO Design Concepts Design classes
Entity classes - they represent things that are to be stored in a database and persist throughout the duration of the application
Boundary classes - used to create the interface that the user sees and interacts with as the software is used.
Controller classes - manage a “unit of work” from start to finish
Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses
Messages—stimulate some behavior to occur in the receiving object
Polymorphism—a characteristic that greatly reduces the effort required to extend the design

47. Inheritance Design options:
The class can be designed and built from scratch, that is, inheritance is not used.
The class hierarchy can be searched to determine if a class higher in the hierarchy (a superclass) contains most of the required attributes and operations. The new class inherits from the superclass and additions may then be added, as required.
The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class.
Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for the new class.

48. 3.9. Design Classes
Refine analysis classes by providing detail needed to implement the classes
Create a new set of design classes that implement a software infrastructure to support the business solution

49. Types of Design Classes
User interface classes – define all abstractions that are necessary for human-computer interaction (HCI)
Business domain classes – are often refinement of the analysis classes defined earlier.
Process classes – implement lower level business abstractions required to fully manage the business domain classes.
Persistent classes – represent data stores that will persist beyond the execution of the software.
System classes - implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.

50. Design Classes
As the design model evolves, the software team must develop a complete set of attributes and operations for each design class.
The level of abstraction is reduced as each analysis class is transformed into a design representation.
Design classes present significantly more technical details as a guide for implementation.

51. ‘Well-formed’ Design Class I
What it is?
Complete and sufficient – i.e. the complete encapsulation of all attributes and methods that can reasonably be expected to exist for the class. Sufficiency ensures that the design class contains only those methods that are sufficient to achieve the intent of the class, no more and no less.
Primitiveness – methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing.

52. ‘Well-formed’ Design Class II
High cohesion – A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.
Low coupling – It is necessary for design classes to collaborate with one another. However, collaboration should be kept to an acceptable minimum. If a design is highly coupled (all design classes collaborate with all other design classes) the system is difficult to implement, to test, and to maintain over time.
The restriction, called the Law of Demeter, suggest that a method should only send messages to methods in neighbouring classes.

53. 4. Design Model Can be viewed in two different dimensions:
Process dimension – indicates the evolution of the design model as design tasks are executed as part of the software process:
- Architecture elements
- Interface elements
- Component-level elements
- Deployment-level elements
Abstraction dimension – represents the level of detail as each element of the analysis model is transformed into a design equivalent and then refined iteratively.
- High level (analysis model elements)
- Low level (design model elements)
Referring to the next figure: the dashed line indicates the boundary between the analysis and design models.

54. The Design Model

55. The Design Model
In some cases, a clear distinction between the analysis and design models is possible.
In other cases, the analysis model slowly blends into the design and a clear distinction is less obvious.
Many UML diagrams used in the design model are refinements of diagrams created in the analysis model The difference is that these diagrams are refined and elaborated as part of design; more implementation specific detail is provided, and architectural structure and style, components that reside within the architecture, and interfaces between the components and with the outside world are emphasized.

56. Design Model Elements Data elements Architectural elements
Data model --> data structures
Data model --> database architecture
Architectural elements
Application domain
Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations
Patterns and “styles” (Chapter 10)
Interface elements
the user interface (UI)
external interfaces to other systems, devices, networks or other producers or consumers of information
internal interfaces between various design components.
Component elements
Deployment elements

57. The Design Model
The model elements noted along the process dimension axis are not always developed in a sequential fashion.
In most cases preliminary architectural design sets the stage and is followed by interface design and component-level design, which often occur in parallel.
The deployment model is usually delayed until the design has been fully developed.

58. 4.1. Data Design
High level model depicting user's view of the data or information
Design of data structures and operators is essential to creation of high-quality applications
Translation of data model into database is critical to achieving system business objectives
Reorganizing databases into data warehouse enables data mining or knowledge discovery that can impact success of business itself

59. 4.2. Architectural Design Equivalent to the floor plan of a house.
The floor plan depicts the overall layout of the rooms, their size, shape and relationship to one another, and the doors and windows that allow movement into and out of the rooms.
The floor plan gives us an overall view of the house
Architectural design elements give us an overall view of the software.

60. Architectural Design Derived from:
Information about the application domain relevant to software
Relationships and collaborations among specific analysis model elements
Availability of architectural patterns and styles
Usually depicted as a set of interconnected systems that are often derived from the analysis packages

61. 4.3. Interface Design
Interface is a set of operations that describes the externally observable behavior of a class and provides access to its operations
Equivalent to a set of detailed drawings (and specifications) for the doors, windows and external utilities of a house.
The detailed drawings (and specifications) for the doors, windows and external utilities which tell us how things and information flow into and out of the house and within the rooms that are part of the floor plan.

62. Interface Design Important elements:
User interface (UI)
External interfaces to other systems
Internal interfaces between various design components
The interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.
An interface is a set of operations that describes some part of the behavior of a class and provides access to those operations.

63. Interface Design Elements
UI - The design of UI incorporates aesthetic elements (e.g. layout, colour, graphics, interaction mechanisms), ergonomic elements (e.g. information layout and placement, UI navigation) and technical elements (e.g., UI patterns, reusable components).
External interfaces – the information about the entity to which information is sent or received should be collected during requirements engineering and verified once the interface design commences. The design of external interfaces should incorporate error checking and (if necessary) appropriate security features.
Internal interfaces – the design of internal interfaces is closely aligned with component-level design. Design realisations of analysis classes represent all operations and the messaging schemes required to enable communication and collaboration between operations in various classes.

64. Interface Elements Modeled using UML collaboration diagrams
The ControlPanel class (next figure) provides the bahavior associated with a keypad, and must implement operations readKeyStroke() and decodeKey(). If these operations are to be provided to other classes, it is useful to define an interface (<<interface>> stereotype) – defined with no attributes and the set of operations that are necessary to achieve the behavior of a keypad.
The dashed line with an open triangle at its end indicates that the ControlPanel class provides KeyPad operations as part of its behavior. In UML, this is characterised as a realisation. That is, part of the behavior of ControlPanel will be implemented by realising KeyPad operations. These operations will be provided to other classes that access the interface.

65. Interface Elements

66. 4.4. Component-Level Design
Equivalent to a set of detailed drawings (and specifications) for each room in a house.
These drawings depict wiring and plumbing within each room, the location of electrical switches, sinks, showers, tubs.
They also describe the flooring to be used, the moulding to be used and every other detail associated with a room.
The component-level design for software fully describes the internal detail of each software component.

67. Component Elements
Describes the internal detail of each software component
Defines
Data structures for all local data objects
Algorithmic detail for all component processing functions
Interface that allows access to all component operations
Modeled using UML component diagrams, UML activity diagrams, and pseudocode (PDL)

68. Component Elements
Within the context of object-oriented software engineering, a component is represented in UML diagrammatic form as shown in the figure on the next slide.
In this figure, a component named SensorManagement (part of the SafeHome security function) is represented. A dashed arrow connects the components to a class named Sensor that is assigned to it. The SensorManagement component performs all functions associated with SafeHome sensors including monitoring and configuring them.

69. Component Elements

70. 4.5. Deployment Elements
Indicates how software functionality and subsystems will be allocated within the physical computing environment
Modeled using UML deployment diagrams
For example, the elements of the SafeHome product are configured to operate within three primary computing environments: a home based PC, the SafeHome control panel, and a server housed at CPI Corp. (providing Internet-based access to the system)

71. Deployment Elements

72. Deployment Elements
The diagram shown in previous figure is in descriptor form – the deployment diagram shows the computing environment, but does not explicitly indicate configuration details.
For example, the ‘personal computer’ is not further identified.
The details are provided when the deployment diagram is revisited in instance form during latter stages of design or as a construction begins. Each instance of the deployment (a specific, named hardware configuration) is identified.

73. 5. Design Patterns
The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution
A description of a design pattern may also consider a set of design forces.
Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied.
The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.

74. Design Pattern Template I
Pattern name - describes the essence of the pattern in a short but expressive name
Intent - describes the pattern and what it does
Also-known-as - lists any synonyms for the pattern
Motivation - provides an example of the problem
Applicability - notes specific design situations in which the pattern is applicable
Structure - describes the classes that are required to implement the pattern

75. Design Pattern Template II
Participants - describes the responsibilities of the classes that are required to implement the pattern
Collaborations - describes how the participants collaborate to carry out their responsibilities
Consequences - describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented
Related patterns - cross-references related design patterns

76. Using Patterns in Design
Once the analysis model has been developed, the designer can examine a detailed representation of the problem to be solved and constraints that are imposed by the problem.
The problem description is examined at various levels of abstraction to determine if it is amenable to one or more types of design patterns

77. Design Patterns
Architectural patterns - define overall structure and relationships of software components (classes, packages, subsystems)
Design patterns - address specific design elements (component aggregations, component relationships, or communication)
Idioms (coding patterns) - language specific implementations for algorithms or communications mechanisms

78. Framework
An implementation-specific skeletal infrastructure needed for design work.
It is not an architectural pattern
Collection of "plug points" hooks or slots that enable it to be adapted to a specific problem domain
Plug points enable designers to integrate problem specific functionality within the skeleton
In an object-oriented context a skeleton is a collection of cooperating classes

79. Summary I
Design engineering commences as the first iteration of requirements engineering comes to a conclusion.
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 design process moves from a ‘big picture’ view of software to a more narrow view that defines detail required to implement a system.
The process begins by focusing on architecture. Subsystems are defined; communication mechanisms among subsystems are established; components are identified; and a detailed description of each component is developed.

80. Summary II The design model encompasses four different elements:
The architectural element - uses information derived from the application domain, the analysis model, and available catalogs for patterns and styles to derive a complete structural representation of the software, its subsystems and components.
Interface design elements - model external and internal interfaces and the user interface.
Component-level elements define each of the modules that populate architecture.
Deployment-level design elements allocate the architecture, its components, and the interfaces to the physical configuration that will house the software.

81. 2005F Instructor John D Lin - johndlin@hotlinemail.com Lectures
Tues & Thurs 10:00-11:30 RM. 100, Lower Block