Software Design

Prof P Karthikeyan

INTRODUCTION:

The word 'design' as defined in the Longman Dictionary of Contemporary English(1987) has the following meanings. As a noun, it means: A drawing or pattern showing how something is to be made; The art of making such drawings or patterns; The arrangement of parts in any man-made product, such as a machine or work of art, as this influences the product's practical usefulness; A decorative pattern, esp. one that is not repeated; A plan in the mind. As a Verb it means: To make a drawing or pattern of (something that will be made or built); develop and draw the plans for; To plan or develop for a certain purpose or use.

Chapter 1 Characteristics of Design Activities

The input and start point of designs

The outcome and results of design

Transformation of data Generation of new ideas

Problem solving and decision making

Satisfying and discovering constraints Evolution and optimization in a solution space of

diversity

Essential Elements of Designs

1. Statement of design and objectives a. No definitive formulation of the problem b. No definitive solution to the problem c. No definitive way of solving the problem 2. Constraints a. The generator of the constraint b. The domain of the constraint 3. Description of product 4. Rationale 5. Plan of production 6. Description of usage

The factors that affect designs Part 1

The difficulties involved in creating software-based systems have

long been recognized.

While apparently-related technology such as hardware design and

production has raced along gaining orders of magnitude in performance, and similarly reducing price and size, software development techniques seem to have inched along in a series of relatively small steps.
Various reasons are sited for this, and in his widely acclaimed

paper No silver bullet: Essence and accidents of software

engineering, Fred Brooks has pointed out some of the principal causes of this relatively slow progress (Brooks 1987).

Brooks cites the following properties of software as major factors affecting its development.
Complexity: Essential property of software, no two parts are alike,

system may possess many states during execution, is arbitrary, dependent upon the designer rather than the problem.
Conformity: Software, being pliable (flexible) is expected to conform

to the standards imposed by other components, such as hardware, or by external bodies, or by existing software.
Changeability: Software suffers constant need for change, partly

because of the apparent ease of making changes (and relatively poor techniques for costing them).
Invisibility: Because software is invisible any forms of representation

that are used to describe it will lack any form of visual link that can provide an easily grasped relationship between the representation and the system

The factors that affect designs Part 2

The principle of totality 2. The Principle of Time 3. The Principle of Value 4. The Principle of Resources 5. The Principle of Synthesis 6. The Principle of Iteration 7. The Principle of Change 8. The Principle of Relationships In addition to software designers, other stakeholders involved in software design include: Customers, users, system administrator, Project managers, Developers, Requirements analysts, Designers, Programmers, Testers, Auditors. 9. The principle of Competence 10. The principle of Service
1.

Chapter 2. Design Qualities:

From David Budgen Book

Concept:
Example of good quality
Quality of construction of the design rather than design.

To achieve high quality in design products it is required to seek high standards in design process.
Is associated with visual properties.

Ultimate measure of quality should normally be that of fitness for purpose.

Assessing design quality when you can measure what you are speaking about,
and express it in numbers, you know something about it, but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind Lord Kelvin 1 A Frame work for assessment: Fenton and Pflegger (1997) have observed that measurement is concerned with capturing information about attributes of entities, so at this point it is useful to identify more carefully how our ideas about quality can be tied to ideas about measurement.

Key terms used in mapping quality concepts to measurements

Quality concepts: are the abstract ideas that we have about what constitutes good and bad properties of a system, and which will need to be assessed by the designer when making decisions about design

choices.
Design attributes: provide a set of measurable (or at least, identifiable) characteristics of the design entities and so provide mapping between the abstract idea of a property and the countable features of an actual design (and therefore effectively correspond to the general concept of a metric). Counts: are concerned with realizing the design attributes, and so

involve identifying the lexical features of a representation that will need

to be counted in order to obtain some form of values for the metrics.

Role

Examples

Abstraction of quality

Quality concept (property)

Complexity the ilities

Metric definition

Measurable characteristic

McCabes Cyclomatic Complexity, Henry and Kafuras Information Flow Counting tokens, counting arcs, etc

Realization of metric

Counts taken from representations

Mapping quality concepts to measurements

A fuller mapping from concepts of quality to countable attributes of a design/implementation

Role

Use

Examples

Purpose of measurement Abstraction of quality

Quality factors (properties)

Complexity the ilities

Associated System attributes

Quality criteria

Completeness, Consistency, Modularity, Machine independence McCabes Cyclomatic Complexity, Henry and Kafuras Information Flow Counting tokens, counting arcs, etc

Metric definition

Measurable characteristic

Realization of metric

Counts taken from representations

Use: identifies the purpose of making measurements (and hence strongly differentiates between measuring static properties of a design and measuring dynamic behavioral qualities);

Quality: factors determine the quality concepts that are associated

with the purpose (these items are often referred to as the ilities). Quality criteria: relate the requirements-oriented properties of the intended system (the ilities) to the solution-oriented properties of the design itself, and these are then mapped onto a chosen set of metrics.

Reliability Operation

Accuracy Completeness Consistency Storage Organization

Efficiency
CPU Utilization

Maintainability Revision Testability

Modularity Structuredness

For a real-time control system: based upon the criteria identified in Fenton and Pflegger (1997) Figure: Mapping quality factors to quality criteria

Reliability Operation

Accuracy Completeness
Consistency Accessibility

Usability Legibility Maintainability Revision Testability Transfer Portability Machine-independence Reusability For a complier : based upon the criteria identified in Fenton and Pflegger (1997) Figure: Mapping quality factors to quality criteria Modularity Structuredness

2. The ilities:

Are used to form a group of quality factors that need to be

considered when making any attempt to assess design quality. They are

Reliability, Efficiency, Maintainability, Usability

Reliability: Complete: in the sense of being able to handle all combination of

events and system states;

Consistent: in that its behavior will be expected, and will be repeatable, regardless of the overall system loading at any time; Robust: when faced with component failure or some similar conflict

Efficiency: The efficiency of a system can be measured through its use of resources such as processor time, memory, network access, system facilities, disk space and so on. There is no single scale on which to specify an optimum efficiency

Maintainability: As systems get larger and more costly, the need to offset
this by ensuring a long life-time in service increases in parallel. To help to achieve this, designs must allow for future modification. Implementation factors affect maintainability. Usability: There are many issues that can affect usability, but for many systems the design of the user interface (HCI) will form an important component, and will influence other design decisions about such

features as module boundaries and data structures.

3. Cognitive dimensions: The ilities are by no means the only framework that we can employ for thinking about system properties within a quality context. A useful set of concepts that originated in the field of HCI is proved by Greens Cognitive Dimensions framework Refer next page for the dimensions(Next page)

The cognitive dimensions

Dimensions Abstraction Hidden dependencies Premature commitment Secondary notation Viscosity Visibility Interpretation Types and availability of abstraction mechanisms. Important links between entities are not visible Constraints on the order of doing things Extra information provided via means other than formal syntax Resistance to change Ability to view components easily

Closeness of mapping
Consistency

Closeness of representation to domain

Similar semantics are expressed in similar syntactic forms Verbosity of language Notation invites mistakes High demand on cognitive resources Work-to-date can be checked at any time

Diffuseness Error-proneness Hard Mental operations Progressive evaluation

Provisionality
Role-Expressiveness

Degree of commitment to actions or marks

The purpose of component is readily inferred

The cognitive dimensions..continued

. Premature commitment (and enforced look ahead): Early design-Early decision which is unavoidable, Measure that can be applied to HCI designs, for our purposes, measure of the quality of the design process, rather than of the

design product.
Hidden dependencies: This concept describes a relationship between two components, such that while one is dependent upon the other the relationship is not fully visible Secondary notation: Other than official syntax. Local layout conventions when using particular design notations Viscosity: Describes the concepts of resistance to change. During design development this may well arise as a consequence of premature commitment, and during maintenance it may be a significant reflection of the resulting design quality. (Modification of a static value)

3.3 Quality attributes of the design product: Some problems have been examined about design quality concepts: To identify a set of design attributes that are related to these properties; To find ways of extracting information about these attributes from the

available forms of
3.3.1. Some Design attributes 3.3.2. Assessing design quality 3.3.1 Some Design Attributes: Simplicity, Modularity, Information-hiding,

Simplicity:
Characteristic of almost all good designs, in whatever sphere of activity they are produced, is a basic simplicity Often-quoted a solution should be as simple as possible, but no

simpler, which is usually attributed to Albert Einstein is more profound than

it might seem at first. This is the opposite of the argument against attempting to oversimplify, since the result will be a product that will not be able to do its job.

One important aid to achieving simplification is abstraction but it is

necessary to use an abstraction that preserves the relevant attributes if it is to be of any help in solving the problem.

Next Page continues (simplicity)..

Simplicity cannot be accessed, one can at least seek measures for its converse characteristics of complexity. Measures..for s/w: 1. Complexity of control flow(McCabe,1976), concerned with the number of possible paths of control during execution of a program unit; 2. Complexity of structure in terms of information flow around the

system(Henry and Kafura, 1984; Kitchenham et al., 1990; Shepperd and Ince,
1993); 3. Complexity of comprehension, as measured by the number of different identifiers and operators (Halstead,1977); 4. Complexity of structure in terms of relationships between system elements (Primarily object-oriented forms), with the measures proposed in Chidamber and Kemerer(1994) being particulary widely cited, although by no means the only candidated (Briand et al., 2000). There are no ready measures that can currently be used to help assess the

architectural complexity of a design.

In terms of the design quality concepts, simplicity is clearly related to maintainability and testability as well as reliability and possibly efficiency.

Modularity: The use of an appropriate form of modular structuring makes it possible for a given problem to be considered in terms of a set smaller components. Not only related to s/w but to engg., To make good use of a modular structure, one needs to adopt a design practice based on a separation of concerns. of

Simplify defining interfaces is not enough; a designer needs to group

functions within modules in such a way that their interdependence is minimized. Such a grouping results in a less complex interface to the module; in the case of hardware, it may simply be that fewer interconnections are required; for software, we need to find other criteria in order to measure this factor.

Modularity Benefits: Modules are easy to replace Each module captures one feature of problem, so aiding comprehension ( and hence maintenance), as well as providing a framework for designing as a team; A well-structured modules can easily be reused for another problem So in terms of the design properties, modularity should be related to such quality concepts as maintainability, testability and (possibly) to usability and reliability too. There are 2 quality measure to assess Modularity: Coupling, Cohesion Coupling: is a measure of intermodule connectivity, and is concerned with identifying the forms of connection that exist between modules and the strength of these connection

Forms of module coupling

Form
Data coupling

Features
Modules A and B communicate by parameters of data items that have no control element Modules A and B make use of some common data type (although they might perform very different functions and have no other connections

Desirability
High

Stamp coupling

Moderate

Control Coupling (i) Activating

A transfers control to B in a structured manner such as by means of a procedure call A Passes a parameter to B that is used in B to determine the actions of B (typically a boolean flag) A and B contain references to some shared data area that incorporate knowledge about its structure and organization. Any change to the format of the block requires that all of the modules using it must also be modified

Necessary

(ii) Coordinating

Undesirable

Common environment coupling

Undesirable

Cohesion: in its turn, provides a measure of the extent to which the components of a module can be considered to be functionally related.

Form
Functional

Features

Desirability

All the elements contribute High to the execution of a single problem-related task The outputs from one Quite element of the module form high the inputs to another element with operations that use the same input or output data Fairly

Sequential

Communicational All elements are concerned

Procedural

The elements of the module are related by the order in which their operations must occur The elements involve operations that are related by the time at which they occur, usually being linked to some event such as system initialization

Not very

Temporal

Not very

Logical

The elements perform operations that are logically similar, but which involve very different actions internally The elements are not linked by any conceptual link(such modules may be created to avoid having to repeat coding tasks)

Definitely not

Coincidental

Definitely not

Information Hiding: related to modularity, and incorporates additional notions

about managing information in a system.

It encourages the designer to keep information about the detailed forms of such objects as data structures and device interfaces local to a module, or a unit, and to ensure that such information should not be made visible outside that

unit(Parnas, 1972).
3.3.2 Assessing the design Quality: Design review cannot provide any well-quantified measures of quality. Used to identify weakness in design Technical review: mental execution of the design model, assessing dynamic and static attributes, Management review: Schedule, project deadlines 8 requirements for a good design: Well structured, simple, efficient, adequate, flexible, practical, implementable, standardized,