• 5.1 Design issues
• 5.2 Classical Design Methods
• 5.3 Object-Oriented Analysis and Design Methods
• 5.4 Architecture design
• 5.5 Design Patterns
• 5.6 Design Documentation
• 5.7 Verification and Validation
• 5.8 Selection of Design Method

5.1 Design issues

Design is a problem-solving activity which depends on on project team experience, their trials and errors. The outcome of this process will be termed the design or the design specification. The quality of the design determines the quality of the resulting product. Errors made during the design phase often go undetected until the system is operational. At that time, they can be repaired only by incurring very high costs.

During design developers should take two points of view: technical and user. Functionality-centered view considers the design problem as a purely technical issue. But design involves user issues as well and therefore needs some form of user involvement. The various possible modes of interaction between the designer or analyst on the one hand and the user on the other hand should be taken to meet organizational and social needs during software design.

From the technical point of view, the design problem can be formulated as follows: how to decompose a system into parts such that each part has a lower complexity than the whole system, while the parts together solve the user’s problem. Since the complexity of the separate components should be reasonable, it is important that the interaction between components not be too complicated.

Design has both a product aspect and a process aspect. The product aspect refers to the result, while the process aspect is about how to get there. At the very global, architectural levels of design, there is little process guidance, and the result is much determined by the experience of the designer. But for the more detailed stages of software design too, the representational aspect is the more important one. This representation is the main communication conductor between the designer and the other stakeholders. Unlike more classical design fields, there is no visual link between the design representations of a software system and the ultimate product.

There is no universal design method. The design process is a creative one, and the quality and competence of the designers are a critical factor for its success. However, over the years a number of ideas and guidelines have emerged which may serve in design process of software development.

During software design is applied abstraction which means that designers concentrate on the essential issues and ignore details that are irrelevant at this stage. Considering the complexity of the problems designers are to solve, applying some sort of abstraction is a real necessity. It is simply impossible to take in all the details at once.

A lsrge number of design methods exist, many of which are strongly tied to a certain notation. These methods give strategies and heuristics to guide the design process. Most methods use a graphical notation to depict the design. Though the details of those methods and notations differ widely, it is possible to provide broad characterizations in a few classes. The essential characteristics of those classes are design patterns. They are collections of a few modules (or classes) which are often used in combination, and which together provide a useful abstraction. A design pattern is a recurring solution to a standard problem. The opposite of a pattern is an antipattern: a mistake often made. The prototypical example of a pattern is the MVC (Model-View-Controller) pattern.

During the design process too, quite a lot of documentation will be generated. This documentation serves various users, such as project managers, designers, testers, and programmers. IEEE Standard 1016 contains useful guidelines for describing software designs. The standard identifies a number of roles and indicates, for each role, the type of design documentation needed.

Also design needs some verification and validation techniques.

Discussing design process it is used the notion of ‘module’. At the programming language level, a module usually refers to an identifiable unit with respect to compilation. A similar definition of the term ‘module’ will be used with respect to design: a module is an identifiable unit in the design. It may consist of a single procedure, or a class, or even a set of classes. It preferably has a clean interface to the outside world, and the functionality of the module then is only approached through that interface.

There are many ways to decompose a system into modules. The most interesting design features which are facilitate maintenance and reuse: simplicity, a clear separation of concepts into different modules, and restricted visibility of information. Systems that have those properties are easier to maintain since developers may concentrate there attention on those parts that are directly affected by a change. These properties also bear on reusability, because the resulting modules tend to have a well-defined functionality that fits concepts from the application domain. Such modules are likely candidates for inclusion in other systems that address problems from the same domain.

Five interrelated issues that have a strong impact on the above features:

• Abstraction - concentration on the essential features and ignore, abstract from, details that are not relevant at the level we are currently working.
• Modularity - the system is decomposed into a number of modules and the relationships between those modules are indicated.
• Information hiding - each module has a secret which it hides to other modules.
• Complexity - refers to attributes of the software that affect the effort needed to construct or change a piece of software. It is two types of complexity metrics (Size-based, Structure-based).
• System structure - depict the outcome of the design process, a set of modules and their mutual dependencies, in a graph (the nodes of this graph correspond to modules and the edges - relations between modules).

5.2 Classical Design Methods

There exist a huge number of design methods, a sample of which is given in figure 5.1. These design methods generally consist of a set of guidelines and procedures on how to design a system. They also offer a notation to express the result of the design process. Together these provide a systematic means for organizing and structuring the design process and its products.

 

 

5.3 Object-Oriented Analysis and Design Methods

The key concepts that play a role in the object-oriented approach to analysis and design: objects, their attributes and services, and the relationships between objects. It follows quite naturally from the above that the object-oriented approach to systems analysis and design involves three major steps:

1. identify the objects;
2. determine their attributes and services;
3. determine the relationships between objects.

Obviously, these steps are highly interrelated and some form of iteration will be needed before the final design is obtained. The resulting picture of the system as a collection of objects and their interrelationships describes the static structure of the system. Class diagram is a graphic variant of this static model is graphically.

An object instance is created, updated zero or more times, and finally destroyed. Finite state diagrams depicting the possible states of an object and the transitions between those states are a good help in modeling this life cycle. Object-oriented methods generally use some variant of the state machine diagram of UML to show this dynamic model of the behavior of system components. Components of the system communicate by sending messages. These messages are part of a task that the system has to perform. Designers may find out which messages are needed, and in which order they have to be exchanged, by considering typical usage scenarios. As was pointed above scenario analysis is a requirements elicitation technique. In object-oriented methods, this technique is called as use-case analysis. The resulting model of the communication between system components is depicted in a sequence or communication diagram.

There are three design methods that show the evolution of object-oriented analysis and design:

• the Booch method, an early object-oriented analysis and design method, with an emphasis on employing a new and rich set of notations.
• Fusion, developed at HP, with a much larger emphasis on the various process steps of the method.
• the Rational Unified Process (RUP), a full life cycle model associated with UML.

The global process model of the Booch method consists of four steps:

• identify classes and objects
• identify semantic of classes and objects
• identify relationships between classes and objects
• specify the interfaces and implementation of classes and objects

The process is iterative, so each of the steps may have to be done more than once. The first cycles are analysis-oriented, while later ones are design-oriented. The blurring of activities in this process model is intentional. Analysis and design activities are assumed to be under control. It is therefore not deemed realistic to prescribe a purely rational order for the activities to be carried out.

The Fusion method for object-oriented analysis and design has two major phases: analysis and design. The analysis phase is aimed at determining the system’s objects and their interactions. The static structure is shown in a class diagram (in Fusion called an object model), and documented in a data dictionary. The dynamics are shown in the interface model. The interface model consists of a life cycle model for each object, denoted by a regular expression (i.e., a flat representation of a state machine diagram) and a specification of the semantics of each operation in a pre- and postcondition style. The analysis process is iterative process. This iteration stops when the models are complete and consistent.

The Rational Unified Process (RUP) is a full process model; see also Unit 8. RUP has a number of workflows, such as a requirements workflow, analysis and design workflow, and test workflow, and four phases: inception, elaboration, construction, and transition. Workflows describe the activities to be carried out, while the phases indicate the organization along the time axis. Most workflows extend over most phases.

RUP is an iterative process, so this transformation is carried out in a number of iterations as well. The first iterations take place in the elaboration phase of RUP. In that phase, the architecture of the system is determined. The RUP way of doing architectural design reasonably fits the global workflow model. In subsequent iterations, concerning the lower-level design, the main activities are termed Analyze behavior and Design components. The purpose of the Analyze behavior step is to transform the use cases into a set of design elements that together serve as a model of the problem domain. It is about what the system is to deliver. It produces a black box model of the solution. The purpose of the Design elements step is to refine the definitions of the design elements into classes, relationships, interfaces and the like. In this activity, the black box what-model is turned into a white box how-model. During both activities, the resulting design is reviewed, and the results thereof are fed back into the next iteration.

5.4 Architecture design

During the design phase, the system is decomposed into a number of interacting components. The top-level decomposition of a system into major components together with a characterization of how these components interact, is called its software architecture. Viewed this way, software architecture is global design of the system.

Software architecture serves three main purposes:

• It is a mean for communication among stakeholders. A software architecture is a global, often graphic, description that can be communicated with the customers, end users, designers, and so on. By developing scenarios of use, relevant quality aspects can be analyzed and discussed with various stakeholders. The software architecture also supports communication during development. It can be used to develop a prelaminar version of the system. The skeletal system can be used as an environment for the incremental implementation of the system. It can also be used as an environment for testing the system.
• It captures early design decisions. In a software architecture, the global structure of the system has been decided upon, through the explicit assignment of functionality to components of the architecture. These early design decisions are important since their ramifications are felt in all subsequent phases. Therefore it is paramount to assess their quality at the earliest stages. By evaluating the architecture, a first and global insight into important quality aspects can be obtained. The global structure decided upon at this stage also structures development: the work-breakdown structure may be based on the decomposition chosen at this stage, testing may be organized around this same decomposition.
• It is a transferable abstraction of a system. The architecture is a basis for reuse. Design decisions are often ordered, from essential to nice features. The essential decisions are captured in the architecture, while the nice features can be decided upon at a later stage. The software architecture thus provides a basis for a family of similar systems, a so-called product line. The global description captured in the architecture may also serve as a basis for training, e.g. to introduce new team members.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The architecture design process is very much driven by the architect’s experience. An experienced architect knows how to handle a given issue, rather than that some method tells him how to perform a design iteration. This is also true for the design methods that are applied at the more detailed levels of design. Their descriptions usually give much more guidance than those for architecture design methods. Since architecture design is usually done by experienced designers, the amount of guidance given, and needed, is less. Attention then shifts to techniques for documenting the result of the design process: the decisions, their rationale, and the resulting design.

ISO/IEEE Std 42010:2011 gives a general structure for software architecture representations. The main elements from this standard are:

• Аrchitecture - fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
• Stakeholder - an individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system.
• View - a representation of a whole system from the perspective of a related set of concerns.
• Viewpoint - a viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view.

So the stakeholder concerns determine which representations, called views, are appropriate for a specific software architecture. Each view has a corresponding viewpoint which gives the ‘syntax’ of the view, much like a construction drawing has an accompanying description telling what all the glyphs in the drawing mean.

Architecture is a (formal) arrangement of architectural elements. An architectural style abstracts from the specifics of an architecture and concentrate on the types of its elements and their interconnections. A software design based on abstract data types emphasizes separation of concerns by encapsulating data. It is emphasizes bundling of functionality in independent processes. In fig.5.2 some most used architectural styles are listed.

 

5.5 Design Patterns

A design pattern is a recurring structure of communicating components that solves a general design problem within a particular context. A design pattern differs from an architectural style in that it does not address the structure of a complete system, but only that of a few interacting components. On the other hand, a design pattern embody more than a single component, procedure or module.

The archetypical example of a design pattern is the Model-View-Controller (MVC) pattern. MVC pattern separates the computational elements from those that handle I/O. MVC involves three components: the Model, the View, and the Controller. The model component encapsulates the system’s data as well as the operations on those data. The model component is independent of how the data is represented or how input is done. A view component displays the data that it obtains from the model component. There can be more than one view component. Finally, each view has an associated controller component. A controller handles input actions. Such an input action may cause the controller to send a request to the model, for example to update its data, or to its view, for example to scroll.

When describing patterns it is customary to use a schema:

• context - the situation giving rise to a design problem
• problem - a recurring problem arising in that situation
• solution - a proven solution to that problem

Most design patterns found in (Gamma et al., 1995) and (Buschmann et al., 1996), offer elegant and flexible solutions to different types of design situations.

Patterns describe common practices that have proven useful. Next to collections of patterns, software developers have formed collections of mistakes often made, and described them as antipatterns. Knowledge of antipatterns is useful during design to prevent common faults, and during evolution to improve an design by using refactoring technique.

 

5.6 Design Documentation

A description of the design serves different users, who have different needs. A proper organization of the design documentation is therefore very important. IEEE Standard 1016 discusses guidelines for the description of a design. This standard mainly addresses the kind of information needed and its organization. For the actual description of its constituent parts any existing design notation can be used.

The design process documentation includes information pertaining to the design status, alternatives that have been rejected, and revisions that have been made. IEEE Std 1016 distinguishes ten attributes, which are minimally required in each SD project. The attributes from IEEE Standard 1016 are:

• Identification - the component’s name, for reference purposes. This name must be unique.
• Type - the kind of component, such as subsystem, procedure, module, file.
• Purpose - what is the specific purpose of the component. This entry will refer back to the requirements specification.
• Function - what does the component accomplish. For a number of components, this information will occur in the requirements specification.
• Subordinates – which components the present entity is composed of. It identifies a static is-composed-of relation between entities.
• Dependencies - a description of the relationships with other components. It concerns the uses-relation and includes more detailed information on the nature of the interaction (including common data structures, order of execution, parameter interfaces, etc.).
• Interface - a description of the interaction with other components. This concerns both the method of interaction and rules for the actual interaction (data formats, constraints on values and the meaning of values).
• Resources - the resources needed. Resources are entities external to the design, such as memory, printers, or a statistical library.
• Processing - a description of algorithms used, way of initialization, and handling of exceptions. It is a refinement of the function attribute.
• Data - a description of the representation, use, format and meaning of internal data.

In IEEE 1016 the attributes have been gathered into four groups (table 5.1). It is interesting to note that each group has its own view on the design. Each view gives a complete description, concentrating on certain aspects of the design.

Table 5.1 - Views on design

Design view	Description	Attributes	User roles
Decomposition	Decomposition of the system into modules	Identification, type, purpose, function, subcomponents	Project manager
Dependencies	Relations between modules and between resources	Identification, type, purpose, dependencies, resources	Configuration manager, maintenance programmer, integration tester
Interface	How to use modules	Identification, function, interfaces	Designer, integration tester
Detail	Internal details of modules	Identification, computation, data	Module tester, programmer

5.7 Verification and Validation

As was pointed above errors made at an early stage are difficult to repair and have high expenses if they are not discovered until a late stage of development. It is therefore necessary to pay extensive attention to testing and validation issues during the design stage.

The way of testing the outcome of the design process strongly depends upon the way in which the design is recorded. The formal specification can be tested formally. It may also be possible to do static tests, such as checks for consistency. Formal specifications may sometimes be executed, which offers additional ways to test the system. Such prototypes are especially suited to test the user interface. A specification-based prototype offers good opportunities for aligning users’ requirements and designers’ ideas.

Is the design is stated in less formal ways, it is limiting the possibilities for testing to forms of reading and critiquing text, such as inspections and walkthroughs. However, such design reviews provide an powerful means for evaluating design.

During the design process the system is decomposed into a number of modules. Testers may develop test cases based on this process. These test cases may be used during functional testing at a later stage. Conversely, the software architecture can be used to guide the testing process. A set of scenarios of typical or expected future usage can be used to test the quality of the software architecture.

5.8 Selection of Design Method

There are several attempts have been made to classify design methods along various parameters, such as the products they deliver, the kind of representations used, or their level of formality. A simple but useful classify method is proposed by Blum in 1994. It has two dimensions: an orientation dimension and a model dimension. In the orientation dimension, a difference is made between problem-oriented techniques and product-oriented techniques. Problem-oriented techniques concentrate on producing a better understanding of the problem and its solution. Problem-oriented techniques are human-oriented. Their aim is to describe, communicate, and document decisions. Conversely, product-oriented techniques focus on a correct transformation from a specification to an implementation. The model dimension relates to the products that are the result of the design process. In this dimension, a difference is made between conceptual models and formal models. Conceptual models are descriptive. They describe an external reality. Their appropriateness is established through validation. Formal models on the other hand are prescriptive. They prescribe the behavior of the software to be developed. Formal models can be verified.

The four quadrants shown in fig.5.5 have the following characteristics:

I) Understand the problem - techniques are concerned with understanding the problem, and expressing a solution in a form that can be discussed with domain specialists (i.e. the users).

II) Transform to implementation - techniques help to transform a collection of domain-related concepts into an implementation structure.

III) Represent properties - techniques facilitate reasoning about the problem and its solution.

IV) Create implementation units - techniques specifically aimed at creating implementation units such as modules.