IT2053 Software Design A Course Material on · IT2053 Software Design SCE Department of Information...

IT2053 Software Design

SCE Department of Information Technology & Computer Applications

A Course Material on

Software Design

By

Mrs.R.Karunya

ASSISTANT PROFESSOR

DEPARTMENT OF INFORMATION TECHNOLOGY

SASURIE COLLEGE OF ENGINEERING

VIJAYAMANGALAM – 638 056



QUALITY CERTIFICATE

This is to certify that the e-course material

Subject Code : IT2053

Subject : Software Design

Class : IV Year IT

being prepared by me and it meets the knowledge requirement of the university curriculum.

Signature of the Author

Name: R.Karunya

Designation: AP

This is to certify that the course material being prepared by Mrs. R.Karunya is of adequate

quality. She has referred more than five books among them minimum one is from abroad author.

Signature of HD

Name: S.ASHOK KUMAR

SEAL



UNIT I GENERAL DESIGN FUNDAMENTALS

1.1 The nature of Design process 1.2 Objectives 1.3 Building Models –1.4 Constructs, 1.5

Design qualities 1.6 Assessing the design 1.7 Design viewpoints for software 1.8 The object Model

1.9 Classes and Objects 1.10 Complexity 1.11 Classification 1.12 Notation 1.13 Process 1.14

Pragmatics

1.1 The nature of Design process

Software design is the process of implementing software solutions to one or more set of

problems. One of the important parts of software design is the software requirements analysis (SRA).

It is a part of the software development process that lists specifications used in software engineering.

If the software is "semi-automated" or user centered, software design may involve user experience

design yielding a story board to help determine those specifications. If the software is completely

automated (meaning no user or user interface), a software design may be as simple as a flow chart or

text describing a planned sequence of events. There are also semi-standard methods like Unified

Modeling Language and Fundamental modeling concepts. In either case, some documentation of the

plan is usually the product of the design. Furthermore, a software design may be platform-

independent or platform-specific, depending on the availability of the technology used for the design.

Software design can be considered as creating a solution to a problem in hand with

available capabilities. The main difference between Software analysis and design is that the output of

a software analysis consist of smaller problems to solve. Also, the analysis should not be very

different even if it is designed by different team members or groups. The design focuses on the

capabilities, and there can be multiple designs for the same problem depending on the environment

that solution will be hosted. They can be operations systems, web pages, mobile or even the new

cloud computing paradigm. Sometimes the design depends on the environment that it was developed

http://en.wikipedia.org/wiki/Software_requirements_analysis

http://en.wikipedia.org/wiki/Software_development_process

http://en.wikipedia.org/wiki/Specifications

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/User_centered_design

http://en.wikipedia.org/wiki/User_experience_design



http://en.wikipedia.org/wiki/Story_board

http://en.wikipedia.org/wiki/Automation

http://en.wikipedia.org/wiki/User_%28computing%29

http://en.wikipedia.org/wiki/User_interface

http://en.wikipedia.org/wiki/Flow_chart

http://en.wikipedia.org/wiki/Unified_Modeling_Language



http://en.wikipedia.org/wiki/Fundamental_modeling_concepts

http://en.wikipedia.org/wiki/Documentation

http://en.wikipedia.org/wiki/Platform-independent_model

http://en.wikipedia.org/wiki/Platform-independent_model

http://en.wikipedia.org/wiki/Platform-specific_model



for, whether it is created from reliable frameworks or implemented with suitable design patterns.

When designing software, two important factors to consider are its security and usability.

1.2 Objectives

Software design is both a process and a model. The design process is a sequence of steps

that enable the designer to describe all aspects of the software to be built. It is important to

note, however, that the design process is not simply a cookbook. Creative skill, past

experience, a sense of what makes ―good‖ software, and an overall commitment to quality are

critical success factors for a competent design. The design model is the equivalent of an

architect‘s plans for a house. It begins by representing the totality of the thing to be built (e.g.,

a three-dimensional rendering of the house) and slowly refines the thing to provide guidance

http://en.wikipedia.org/wiki/Software_framework

http://en.wikipedia.org/wiki/Design_patterns



for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is

created for software provides a variety of different views of the computer software. Basic

design principles enable the software engineer to navigate the design process. Davis [DAV95]

suggests a set of principles for software design, which have been adapted and extended in the

following list:

The design process should not suffer from “tunnel vision.” A good designer should

consider alternative approaches, judging each based on the requirements of the problem, the

resources available to do the job.

The design should be traceable to the analysis model. Because a single element of the

design model often traces to multiple requirements, it is necessary to have a means for tracking

how requirements have been satisfied by the design model.

The design should not reinvent the wheel. Systems are constructed using a set of design

patterns, many of which have likely been encountered before. These patterns should always be

chosen as an alternative to reinvention. Time is short and resources are limited! Design time

should be invested in representing truly new ideas and integrating those patterns that already

exist.

The design should “minimize the intellectual distance” between the software and the

problem as it exists in the real world. That is, the structure of the software design should

(whenever possible) mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears that

one person developed the entire thing. Rules of style and format should be defined for a design

team before design work begins. A design is integrated if care is taken in defining interfaces

between design components.

The design should be structured to accommodate change. The design concepts discussed in

the next section enable a design to achieve this principle.

The design should be structured to degrade gently, even when aberrant data, events, or

operating conditions are encountered. Well- designed software should never ―bomb.‖ It

should be designed to accommodate unusual circumstances, and if it must terminate

processing, do so in a graceful manner.

Design is not coding, coding is not design. Even when detailed procedural designs are created

for program components, the level of abstraction of the design model is higher than source



code. The only design decisions made at the coding level address the small implementation

details that enable the procedural design to be coded.

The design should be assessed for quality as it is being created, not after the fact. A

variety of design concepts and design measures are available to assist the designer in assessing

quality.

The design should be reviewed to minimize conceptual (semantic) errors. There is

sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for

the trees. A design team should ensure that major conceptual elements of the design

(omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of

the design model.

1.3 Design Concepts

The design concepts provide the software designer with a foundation from which more

sophisticated methods can be applied. A set of fundamental design concepts has evolved. They

are:

1. Abstraction - Abstraction is the process or result of generalization by reducing the information

content of a concept or an observable phenomenon, typically in order to retain only

information which is relevant for a particular purpose.

2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a

macroscopic statement of function in a step-wise fashion until programming language

statements are reached. In each step, one or several instructions of a given program are

decomposed into more detailed instructions. Abstraction and Refinement are complementary

concepts.

3. Modularity - Software architecture is divided into components called modules.

4. Software Architecture - It refers to the overall structure of the software and the ways in which

that structure provides conceptual integrity for a system. A good software architecture will

yield a good return on investment with respect to the desired outcome of the project, e.g. in

terms of performance, quality, schedule and cost.

5. Control Hierarchy - A program structure that represents the organization of a program

component and implies a hierarchy of control.

http://en.wikipedia.org/wiki/Modularity

http://en.wikipedia.org/wiki/Software_Architecture

http://en.wikipedia.org/w/index.php?title=Control_Hierarchy&action=edit&redlink=1



6. Structural Partitioning - The program structure can be divided both horizontally and

vertically. Horizontal partitions define separate branches of modular hierarchy for each

major program function. Vertical partitioning suggests that control and work should be

distributed top down in the program structure.

7. Data Structure - It is a representation of the logical relationship among individual

elements of data.

8. Software Procedure - It focuses on the processing of each modules individually

9. Information Hiding - Modules should be specified and designed so that information contained

within a module is inaccessible to other modules that have no need for such information

Design considerations

There are many aspects to consider in the design of a piece of software. The importance of

each should reflect the goals the software is trying to achieve. Some of these aspects are:

Compatibility - The software is able to operate with other products that are designed for

interoperability with another product. For example, a piece of software may be backward-

compatible with an older version of itself.

Extensibility - New capabilities can be added to the software without major changes to the

underlying architecture.

Fault-tolerance - The software is resistant to and able to recover from component failure.

Maintainability - A measure of how easily bug fixes or functional modifications can be

accomplished. High maintainability can be the product of modularity and extensibility.

Modularity - the resulting software comprises well defined, independent components. That

leads to better maintainability. The components could be then implemented and tested in

isolation before being integrated to form a desired software system. This allows division of

work in a software development project.

Reliability - The software is able to perform a required function under stated conditions for a

specified period of time.

Reusability - the software is able to add further features and modification with slight or no

modification.

Robustness - The software is able to operate under stress or tolerate unpredictable or invalid

input. For example, it can be designed with resilience to low memory conditions.

Security - The software is able to withstand hostile acts and influences.

http://en.wikipedia.org/w/index.php?title=Structural_Partitioning&action=edit&redlink=1

http://en.wikipedia.org/wiki/Data_Structure

http://en.wikipedia.org/w/index.php?title=Software_Procedure&action=edit&redlink=1

http://en.wikipedia.org/wiki/Information_Hiding

http://en.wikipedia.org/wiki/Fault-tolerance

http://en.wikipedia.org/wiki/Maintainability

http://en.wikipedia.org/wiki/Modularity

http://en.wikipedia.org/wiki/Reusability

http://en.wikipedia.org/wiki/Fault-tolerant_system

http://en.wikipedia.org/wiki/Computer_security



Usability - The software user interface must be usable for its target user/audience.

Default values for the parameters must be chosen so that they are a good choice for the

majority of the users

Performance - The software performs its tasks within a user-acceptable time. The software

does not consume too much memory.

Portability - The usability of the same software in different environments.

Scalability - The software adapts well to increasing data or number of users

1.4 Building Models

A modeling language is any artificial language that can be used to express information or

knowledge or systems in a structure that is defined by a consistent set of rules. The rules are

used for interpretation of the meaning of components in the structure. A modeling language

can be graphical or textual. Examples of graphical modeling languages for software design are:

Business Process Modeling Notation (BPMN) is an example of a Process Modeling language.

EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data

modeling language.

Extended Enterprise Modeling Language (EEML) is commonly used for business process

modeling across a number of layers.

Flowchart is a schematic representation of an algorithm or a step-wise process,

Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems.

IDEF is a family of modeling languages, the most notable of which include IDEF0 for

functional modeling, IDEF1X for information modeling,and IDEF5 for modeling ontologies.

Jackson Structured Programming (JSP) is a method for structured programming based on

correspondences between data stream structure and program structure

LePUS3 is an object-oriented visual Design Description Language and a formal specification

language that is suitable primarily for modeling large object-oriented (Java, C++, C#)

programs and design patterns.

Unified Modeling Language (UML) is a general modeling language to describe software both

structurally and behaviorally. It has a graphical notation and allows for extension with a Profile

(UML).

http://en.wikipedia.org/wiki/Usability

http://en.wikipedia.org/wiki/Performance

http://en.wikipedia.org/wiki/Software_portability

http://en.wikipedia.org/wiki/Scalability

http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation

http://en.wikipedia.org/wiki/EXPRESS_%28data_modeling_language%29

http://en.wikipedia.org/wiki/Data_modeling



http://en.wikipedia.org/wiki/Extended_Enterprise_Modeling_Language

http://en.wikipedia.org/wiki/Flowchart

http://en.wikipedia.org/wiki/Fundamental_Modeling_Concepts

http://en.wikipedia.org/wiki/IDEF

http://en.wikipedia.org/wiki/IDEF0

http://en.wikipedia.org/wiki/IDEF1X

http://en.wikipedia.org/wiki/IDEF5

http://en.wikipedia.org/wiki/Jackson_Structured_Programming

http://en.wikipedia.org/wiki/Lepus3

http://en.wikipedia.org/wiki/Object-oriented

http://en.wikipedia.org/wiki/Formal_specification

http://en.wikipedia.org/wiki/Java_%28programming_language%29

http://en.wikipedia.org/wiki/C%2B%2B

http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29

http://en.wikipedia.org/wiki/Design_patterns


http://en.wikipedia.org/wiki/Profile_%28UML%29





Alloy (specification language) is a general purpose specification language for expressing complex

structural constraints and behavior in a software system. It provides a concise language based on first-

order relational logic.

Systems Modeling Language (SysML) is a new general-purpose modeling language for systems

engineering.

1.5 Design qualities

A software designer or architect may identify a design problem which has been solved by others

before. A template or pattern describing a solution to a common problem is known as a design

pattern. The reuse of such patterns can speed up the software development process, having been

tested and proven in the past.

Technique

The difficulty of using the term "design" in relation to software is that in some sense, the source code

of a program is the design for the program that it produces. To the extent that this is true, "software

design" refers to the design of the design. referred to this layering of semantic levels as the "radical

novelty" of computer programming , an Donald Knuth used his experience writing TeX to describe

the futility of attempting to design a program prior to implementing it

1.6 Assessing the design

1. Introduction

The following subsections of the Software Design Document (SDD) should provide an overview of

the entire SDD.

1.1 Purpose

This subsection should explain the purpose of the SDD and specify the intended audience for it. The

SDD described the software structure, software components, interfaces and data necessary for the

implementation phase. Each requirement in the SRS should be traceable to one or more design

entities in the SDD.

1.2 Scope

This subsection should relate the design document to the SRS and to the software to be developed.

http://en.wikipedia.org/wiki/Alloy_%28specification_language%29

http://en.wikipedia.org/wiki/Systems_Modeling_Language

http://en.wikipedia.org/wiki/General-purpose_modeling

http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29



http://en.wikipedia.org/wiki/TeX



1.3 Definitions, Acronyms and Abbreviations

This subsection should provide the definitions of all terms, acronyms and abbreviations that are used

in the SDD.

2. References

This subsection should provide a complete list of all documents referenced in the SDD. It should

identify these references by title, report number, date and publishing organization. It should also

specify the sources from which these references are available.

3. Attributes of Design Entities

There are some attributes common to all entities, regardless of the approach utilized, whether

procedural or object-oriented. These are used in subsections 4 and later.

3.1 Identification

The name of the entity should be specified. Two entities should not have the same name.

3.2 Type

The type attribute should describe the nature of the entity. It may simply name the kind of entity, such

as subprogram, module, procedure, process, data item, object . Alternatively, design entities can be

grouped, in order to assist in locating an entity dealing with a particular type of information.

3.3 Purpose

This is a description of why the entity exists. It provides the rationale for the creation of the entity.

Therefore it designates the specific functional and performance requirements for which this entity was

created, using the SRS.

3.4 Function

The function attribute should state the transformation applied by the entity inputs to produce the

desired output. In the case of a data entity, this attribute should state the type of information stored or

transmitted by the entity.

3.5 Subordinates

The subordinates attribute should identify the entities composing this entity. This information is used

to trace requirements to design entities and to identify the parent/child structural relationships through

software system decomposition.

3.6 Dependencies



The dependencies attribute should identify the relationship of the entity with other entities. It

describes the nature of each interaction that may involve initiation, order of execution, data sharing,

creation, duplicating, usage, storage or destruction of other entities.

3.7 Interface

The interface attribute describes how other entities interact with this entity. It should describe the

methods of interaction and rules governing those interactions. It provides a description of the input

ranges, the meaning of inputs and outputs, the type and format of each input or output, and output

error codes.

3.8 Resources

The resources attribute identifies and describes all of the resources external to the design that are

needed by this entity to perform its function. It provides information about items such as physical

devices (printers, discs, memory), software services (math libraries, operating system services,

graphical user interface libraries), and processing resources (CPU cycles, memory allocation).

3.9 Processing

The processing attribute describes the rules used by the entity to achieve its function. It describes the

algorithm used by the entity to perform a specific task. It includes sequencing of events or processes,

process steps, conditions, termination criteria etc.

3.10 Data

The data attribute describes the method of representation, initial value, use, format and acceptable

values of internal data.

4. Decomposition Description

4.1 General Structure

This section of the SDD should record the division of the software system into design entities. It

describes the way the system is structured and the purpose and function of each entity. For each

entity, it provides a reference to the detailed description. It uses the identification, type, purpose,

function and subordinates attributes.

4.2 Procedural Approach

If a procedural approach is used, this includes a description of the basic modules of the system and

how they relate to other modules (which modules it calls etc.) Textual descriptions should also be

provided for each module that the system is decomposed into.

4.2.1 Module Decomposition



This subsection describes the decomposition information as given in 3.1 for software modules.

4.2.2 Data Decomposition

This subsection describes the decomposition information as given in 3.1 for data elements.

4.3 Object-Oriented Approach

4.3.1 Use Case Diagrams

4.3.2 Class Diagrams

4.3.3 Sequence Diagrams

4.3.4 State chart Diagrams

4.3.5 Activity Diagrams

5. Dependency Description

This subsection describes the dependencies between different entities. It uses the identification, type,

purpose, dependencies and resources attributes.

6. Interface Description

This subsection describes everything designers, programmers and testers need to know to correctly

use the functions provided by an entity. It includes the details of external and internal interfaces not

provided in the SRS. It uses the identification, function and interfaces attributes.

7. Detailed Design

It contains the internal details of each design entity. These details include attribute descriptions for

identification, processing and data. It contains all the details that will be needed by the programmers

for implementation. Short English-like descriptions can be used to describe the

algorithms utilized. Data structure details should also be given.



1.7 Design View for software

Abstaction:

Identifying important features for representation.There are many levels of abstraction

depending on how detailed the representation is required

Data abstraction - representation of data objects

Procedural abstraction - representation of instructions

Modularity:

Software is divided into separately named and addressable modules ―Divide and conquer‖

approach - problem is broken into manageable pieces,Solutions for the separate pieces then integrated

into the whole system.

1.8The Object model

Object-oriented technology is built upon a sound engineering foundation, whose elements we

collectively call the object model. The object model encompasses the principles of abstraction,

encapsulation, modularity, hierarchy, typing, concurrency, and persistence.

How you differentiate the object oriented model and traditional structured?

OOM requires a different way of thinking about decomposition, and it produces software

architectures that are largely outside the realm of the structured design culture. These differences arise

from the fact that structured design methods build upon structured programming, whereas object-

oriented design builds upon object-oriented programming. Unfortunately, object-oriented

programming means different things to different people.

Foundations of the Object Model

Object-oriented design methods have evolved to help developers exploit the expressive power

of object-based and object-oriented programming languages, using the class and object as basic

building blocks. Levy adds that the following events have contributed to the evolution of object-

oriented concepts:

"Advances in computer architecture, including capability systems and hardware support for

operating systems concepts



Advances in programming languages, as demonstrated in Simula, Smalltalk, CLU, and Ada

Advances in programming methodology, including modularization and information hiding"

We would add to this list three more contributions to the foundation of the object model:

• Advances in database models

• Research in artificial intelligence

• Advances in philosophy and cognitive science

Elements of the Object Model

They further suggest that there are five main kinds of programming styles, here listed with the

kinds of abstractions they employ:

• Procedure-oriented Algorithms

• Object-oriented Classes and objects

• Logic-oriented Goals, often expressed in a predicate calculus

• Rule-oriented If-then rules

• Constraint-oriented Invariant relationships

Rule-oriented programming would be best for the design of a knowledge base, and procedure-

oriented programming would be best suited for the design of computation-intense operations. From

our experience, the object-oriented style is best suited to the broadest set of applications; indeed, this

programming paradigm often serves as the architectural framework in which we employ other

paradigms. Each of these styles of programming is based upon its own conceptual framework. Each

requires a different mindset, a different way of thinking about the problem. For all things object-

oriented, the conceptual framework is the object model.

There are four major elements of this model:

• Abstraction

• Encapsulation

• Modularity

• Hierarchy

By major, we mean that a model without any one of these elements is not object-oriented.



There are three minor elements of the object model

Typing

Concurrency

Persistence

By minor, we mean that each of these elements is a useful, but not essential, part of the object Model.

Abstraction

An abstraction denotes the essential characteristics of an object that distinguish it from all

other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the

perspective of the viewer.List the different types of abstraction

Entity abstraction

An object that represents a useful model of a problem domain or solution-domain entity

Action abstraction

An object that provides a generalized set of operations, all of which perform the same kind of

function

Virtual machine abstraction

An object that groups together operations that are all used by some superior level of control,

or operations that all use some junior-level set of operations.

Coincidental abstraction

An object that: packages a set of operations that have no relation to each other

Encapsulation

Encapsulation is the process of compartmentalizing the elements of an abstraction that

constitute its structure and behavior; encapsulation serves to separate the contractual interface of an

abstraction and its implementation.

Modularity

Modularity is the property of a system that has been decomposed into a set of cohesive and

loosely coupled modules.

Hierarchy

Hierarchy is a ranking or ordering of abstractions.

Typing

Typing is the enforcement Of the class of an object, such, that objects of different types may

not be interchanged, or at the most, they may be interchanged only in very restricted ways.



Concurrency

Concurrency is the properly that distinguishes an active object from one that is not active.

Persistence

Persistence is the property of an object through which its existence transcends time (i.e. the

object continues to exist after its creator ceases to exist) and/or space (i. e. the objects location moves

from the address space in which it was created).

1.9 Classes and Objects

An object has state, behavior, and identity; the structure and behavior of similar objects are defined

in their common class; the terms instance and object are interchangeable.

The state of an object encompasses all of the (usually static) properties of the object plus the

current(usually dynamic) values of each of these properties.

The Meaning of Behavior No object exists in isolation. Rather, objects are acted upon, and

themselves act upon other objects. Thus, we may say that Behavior is how an object acts and reacts,

in terms of its state changes and message passing.

―Identity is that property of an object which distinguishes it from all other objects‖

Relationships Among Objects

The relationship between any two objects encompasses the assumptions that each makes

about the other, including what operations can be performed and what behavior results. We have

found that two kinds of object hierarchies are of particular interest in object-oriented analysis and

design, namely:

• Links

• Aggregation



Figure Link

Link is a "physical or conceptual connection between objects". An object collaborates with other

objects through its links to these objects.

A line between two object icons represents the existence of a link between the two and means

that messages may pass along this path. Messages are shown as directed lines representing the

direction of the message, with a label naming the message itself. For example, here we see that the

object a Controller has links to two instances of Display Item (the objects a and b). Although both

a and b probably have links to the view in which they are shown, we have chosen to highlight only

once such link, from a to a View. Only across these links may one object send messages to another.

As a participant in a link, an object may play one of three roles:

• Actor An object that can operate upon other objects but is never operated upon by other

objects; in some contexts, the terms active object and actor are interchangeable

• Server An object that never operates upon other objects; it is only operated upon by other

objects

• Agent An object that can both operate upon other objects and be operated upon by other

objects; an agent is usually created to do some work on behalf of an actor or another agent



The Nature of a Class

A class is a set of objects that share a common structure and a common behavior.

The concepts of a class and an object are tightly interwoven, for we cannot talk about an

object without regard for its class. However, there are important differences between these two terms.

Whereas an object is a concrete entity that exists in time and space, a class represents only an

abstraction, the ―essence" of an object, as it were. Thus, we may speak of the class Mammal, which

represents the characteristics common to all mammals. To identify a particular mammal in this class,

we must speak of "this mammal‖ or "that mammal."

The interface of a class provides its outside view and therefore emphasizes the abstraction

while hiding its structure and the secrets of its behavior. This interface primarily consists of the

declarations of all the operations applicable to instances of this class, but it may also include the

declaration of other classes, constants, variables, and exceptions as needed to complete the

abstraction. By contrast, the implementation of a class is its inside view, which encompasses the

secrets of its behavior. The implementation of a class primarily consists of the implementation of all

of the operations defined in the interface of the class.

We can further divide the interface of a class into three parts:

• Public A declaration that is accessible to all clients

• Protected A declaration that is accessible only to the class itself, its subclasses, and its friends

• Private A declaration that is accessible only to the class itself and its friends

Relationships Among Classes

Kinds of Relationships

Consider for a moment the similarities and differences among the following classes of objects:

flowers, daisies, red roses, yellow roses, petals, and ladybugs. We can make the following

observations:

• A daisy is a kind of flower.

• A rose is a (different) kind of flower.

• Red roses and yellow roses are both kinds of roses.



• A petal is a part of both kinds of flowers.

• Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers.

From this simple example we conclude that classes, like objects, do not exist in isolation.

Rather, for a particular problem domain, the key abstractions are usually related in a variety of

interesting ways, forming the class structure of our design. We establish relationships between two

classes for one of two reasons. First, a class relationship might indicate some sort of sharing. For

example, daisies and roses are both kinds of flowers, meaning that both have brightly colored petals,

both emit a fragrance, and so on. Second, a class relationship might indicate some kind of semantic

connection. Thus, we say that red roses and yellow roses are more alike than are daisies and roses,

and daisies and roses are more closely related than are petals and flowers. Similarly, there is a

symbiotic connection between ladybugs and flowers: ladybugs protect flowers from certain pests,

which serve as a food source for the ladybug.

In all, there are three basic kinds of class relationships. The first of these is

generalization/specialization, denoting an "is a" relationship. For instance, a rose is a kind of flower,

meaning that a rose is a specialized subclass of the more general class, flower. The second is

whole/part, which denotes a "part of" relationship. Thus, a petal is not a kind of a flower; it is a part of

a flower. The third is association, which denotes some semantic dependency among otherwise

unrelated classes, such as between ladybugs and flowers. As another example, roses and candles are

largely independent classes, but they both represent things that we might use to decorate a dinner

table.

Several common approaches have evolved in programming languages to capture

generalization/specialization, whole/part, and association relationships. Specifically, most object-

oriented languages provide direct support for some combination of the following relationships:



1.10Classification

• Association

• Inheritance

• Aggregation

• Using

• Instantiation

• Metaclass

These six different kinds of class relationships, associations are the most general but also the most

semantically weak. Inheritance is perhaps the most semantically interesting of these concrete

relationships, and exists to express generalization/specialization relationships. In our experience,

however, inheritance is an insufficient means of expressing all of the rich relationships that may exist

among the key abstractions in a given problem domain. We also need aggregation relationships,

which provide the whole/part relationships manifested in the class's instances. Additionally, we need

using relationships, which establish the links among the class's instances

Association

We may show a simple association between these two classes: the class Product denotes

the products sold as part of a sale, and the class Sale denotes the transaction through which several

products were last sold. By implication, this association suggests bidirectional navigation: given an

instance of Product, we should be able

to locate the object denoting its sale, and given an instance of Sale, we should be able to locate all the

products sold during the transaction.



Semantic Dependencies

An association only denotes a semantic dependency and does not state the direction of this

dependency (unless otherwise stated, an association implies bidirectional navigation, as in our

example), nor does it state the exact way in which one class relates to another (we can only imply

these semantics by naming the role each class plays in relationship with the other). However, these

semantics are sufficient during the analysis of a problem, at which time we need only to identily such

dependencies. Through the creation of associations, we come to capture the participants in a semantic

relationship, their roles, and, as we will discuss, their cardinality.

Cardinality Our example introduced a one-to-many association, meaning that for each instance of the

class Sale, there are zero or more instances of the class Product, and for each product, there is

exactly one sale. This multiplicity denotes the cardinality of the association.

In practice, there are three common kinds of cardinality across an association:

One-to-one

One-to-many

Many-to-many

Inheritance

A subclass may inherit the structure and behavior of its super class. Quality Classes and

Objects

"A system should be built with a minimum set of unchangeable parts; those parts should be as

general as possible; and all parts of the system should be held in a uniform framework"

We suggest five meaningful metrics:

• Coupling

• Cohesion

• Sufficiency

• Completeness



Message passing may thus take one of the following forms:

• Synchronous An operation commences only when the sender has initiated the action and the

receiver is ready to accept the message; the sender and receiver will wait indefinitely until both

parties are ready to proceed.

• Balking The same as synchronous, except that the sender will abandon the operation if the

receiver is not immediately ready.

• Timeout The same as synchronous, except that the sender will only wait for a specified amount

of time for the receiver to be ready.

• Asynchronous A sender may initiate an action regardless of whether the receiver is expecting the

message.

1.11 Class Notation:

UML class is represented by the diagram shown below. The diagram is divided into four parts.

The top section is used to name the class.

The second one is used to show the attributes of the class.

The third section is used to describe the operations performed by the class.

The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.



Object Notation:

The object is represented in the same way as the class. The only difference is the name which

is underlined as shown below.

As object is the actual implementation of a class which is known as the instance of a class. So it has

the same usage as the class.

Interface Notation:

Interface is represented by a circle as shown below. It has a name which is generally written

below the circle.

Interface is used to describe functionality without implementation. Interface is the just like a

template where you define different functions not the implementation. When a class implements the

interface it also implements the functionality as per the requirement.



Collaboration Notation:

Collaboration is represented by a dotted eclipse as shown below. It has a name written inside

the eclipse.

Collaboration represents responsibilities. Generally responsibilities are in a group.

Use case Notation:

Use case is represented as an eclipse with a name inside it. It may contain additional

responsibilities.

Use case is used to capture high level functionalities of a system.



Actor Notation:

An actor can be defined as some internal or external entity that interacts with the system.

Actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation:

Initial state is defined show the start of a process. This notation is used in almost all diagrams.

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation:

Final state is used to show the end of a process. This notation is also used in almost all

diagrams to describe the end.

The usage of Final State Notation is to show the termination point of a process.

Active class Notation:

Active class looks similar to a class with a solid border. Active class is generally used to

describe concurrent behaviour of a system.



Active class is used to represent concurrency in a system.

Component Notation:

A component in UML is shown as below with a name inside. Additional elements can be

added wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation:

A node in UML is represented by a square box as shown below with a name. A node

represents a physical component of the system.

Node is used to represent physical part of a system like server, network etc.



Behavioural Things:

Dynamic parts are one of the most important elements in UML. UML has a set of powerful

features to represent the dynamic part of software and non software systems. These features include

interactions and state machines.

Interactions can be of two types:

Sequential (Represented by sequence diagram)

Collaborative (Represented by collaboration diagram)

Interaction Notation:

Interaction is basically message exchange between two UML components. The following

diagram represents different notations used in an interaction.

Interaction is used to represent communication among the components of a system.



State machine Notation:

State machine describes the different states of a component in its life cycle. The notations are

described in the following diagram.

State machine is used to describe different states of a system component. The state can be active, idle

or any other depending upon the situation.

Grouping Things:

Organizing the UML models are one of the most important aspects of the design. In UML

there is only one element available for grouping and that is package.

Package Notation:

Package notation is shown below and this is used to wrap the components of a system.



Annotational Things:

In any diagram explanation of different elements and their functionalities are very important.

So UML has notes notation to support this requirement.

Note Notation:

This notation is shown below and they are used to provide necessary information of a system.

Relationships

A model is not complete unless the relationships between elements are described properly. The

Relationship gives a proper meaning to an UML model. Following are the different types of

relationships available in UML.

Dependency

Association

Generalization

Extensibility



Dependency Notation:

Dependency is an important aspect in UML elements. It describes the dependent elements and

the direction of dependency.

Dependency is represented by a dotted arrow as shown below. The arrow head represents the

independent element and the other end the dependent element.

Dependency is used to represent dependency between two elements of a system.

Generalization Notation:

Generalization describes the inheritance relationship of the object oriented world. It is parent

and child relationship.

Generalization is represented by an arrow with hollow arrow head as shown below. One end

represents the parent element and the other end child element.

Generalization is used to describe parent-child relationship of two elements of a system.

Association Notation:

Association describes how the elements in an UML diagram are associated. In simple word it

describes how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both sides. The two ends

represent two associated elements as shown below. The multiplicity is also mentioned at the ends (1,

* etc) to show how many objects are associated.



Association is used to represent the relationship between two elements of a system.

Extensibility Notation:

All the languages (programming or modeling) have some mechanism to extend its capabilities

like syntax, semantics etc. UML is also having the following mechanisms to provide extensibility

features.

Stereotypes (Represents new elements)

Tagged values (Represents new attributes)

Constraints (Represents the boundaries)

Extensibility notations are used to enhance the power of the language. It is basically additional

elements used to represent some extra behavior of the system. These extra behaviors are not covered

by the standard available notations.



Unit-II STRUCTURED SYSTEM ANALYSIS AND DESIGN

Structured Design – Design Principles – Problem Partitioning and Hierarchy – Abstraction,

Modularity – Top-down and Bottom-up Strategies – Transformation of a DFD to a Structure Chart –

Transform Analysis – Transaction Analysis – Coupling – Cohesion – Multiple types of Cohesion in a

module – Data Design – Normalization – Denormalization – Procedural Design.

Top-down and Bottom-up Strategies



Transformation of a DFD into Structure Chart- Transaction Analysis

Break the system into suitably tractable units by means of transaction analysis

Convert each unit into into a good structure chart by means of transform analysis

Link back the separate units into overall system implementation

The transaction is identified by studying the discrete event types that drive the system. For example,

with respect to railway reservation, a customer may give the following transaction stimulus:

The three transaction types here are: Check Availability (an enquiry), Reserve Ticket (booking) and

Cancel Ticket (cancellation). On any given time we will get customers interested in giving any of the



above transaction stimuli. In a typical situation, any one stimulus may be entered through a particular

terminal. The human user would inform the system her preference by selecting a transaction type

from a menu. The first step in our strategy is to identify such transaction types and draw the first level

breakup of modules in the structure chart, by creating separate module to co-ordinate various

transaction types. This is shown as follows:

The Main ( ) which is a over-all coordinating module, gets the information about what

transaction the user prefers to do through TransChoice. The TransChoice is returned as a parameter to

Main ( ). Remember, we are following our design principles faithfully in decomposing our modules.

The actual details of how GetTransactionType ( ) is not relevant for Main ( ). It may for example,

refresh and print a text menu and prompt the user to select a choice and return this choice to Main ( ).

It will not affect any other components in our breakup, even when this module is changed later to

return the same input through graphical interface instead of textual menu. The modules Transaction1 (

), Transaction2 ( ) and Transaction3 ( ) are the coordinators of transactions one, two and three

respectively. The details of these transactions are to be exploded in the next levels of abstraction.

We will continue to identify more transaction centers by drawing a navigation chart of all input

screens that are needed to get various transaction stimuli from the user. These are to be factored out in

the next levels of the structure chart (in exactly the same way as seen before), for all identified

transaction centers.

Transform Analysis

Transform analysis is strategy of converting each piece of DFD (may be from level 2 or

level 3, etc.) for all the identified transaction centers. Draw a DFD of a transaction type (usually done

during analysis phase)

Find the central functions of the DFD

Convert the DFD into a first-cut structure chart



Refine the structure chart

Verify that the final structure chart meets the requirements of the original DFD

Let us understand these steps through a payroll system example:

Identifying the central transform

The central transform is the portion of DFD that contains the essential functions of the

system and is independent of the particular implementation of the input and output. One way of

identifying central transform (Page-Jones, 1988) is to identify the centre of the DFD by pruning off its

afferent and efferent branches. Afferent stream is traced from outside of the DFD to a flow point

inside, just before the input is being transformed into some form of output (For example, a format or

validation process only refines the input – does not transform it). Similarly an efferent stream is a

flow point from where output is formatted for better presentation. The processes between afferent and



efferent stream represent the central transform (marked within dotted lines above). In the above

example, P1 is an input process, and P6 & P7 are output processes. Central transform processes are

P2, P3, P4 & P5 - which transform the given input into some form of output.

First-cut Structure Chart

To produce first-cut (first draft) structure chart, first we have to establish a boss module. A

boss module can be one of the central transform processes. Ideally, such process has to be more of a

coordinating process (encompassing the essence of transformation). In case we fail to find a boss

module within, a dummy coordinating module is created

In the above illustration, we have a dummy boss module ―Produce Payroll‖ – which is

named in a way that it indicate what the program is about. Having established the boss module, the

afferent stream processes are moved to left most side of the next level of structure chart; the efferent

stream process on the right most side and the central transform processes in the middle. Here, we

moved a module to get valid timesheet (afferent process) to the left side (indicated in yellow). The

two central transform processes are move in the middle (indicated in orange). By grouping the other

two central transform processes with the respective efferent processes, we have created two modules

(in blue) – essentially to print results, on the right side.

The main advantage of hierarchical (functional) arrangement of module is that it leads to

flexibility in the software. For instance, if ―Calculate Deduction‖ module is to select deduction rates

from multiple rates, the module can be split into two in the next level – one to get the selection and

another to calculate. Even after this change, the ―Calculate Deduction‖ module would return the same

value.



Refine the Structure Chart

Expand the structure chart further by using the different levels of DFD. Factor down till

you reach to modules that correspond to processes that access source / sink or data stores. Once this is

ready, other features of the software like error handling, security, etc. has to be added. A module

name should not be used for two different modules. If the same module is to be used in more than one

place, it will be demoted down such that ―fan in‖ can be done from the higher levels. Ideally, the

name should sum up the activities done by the module and its sub-ordinates.

Verify Structure Chart vis-à-vis with DFD

Because of the orientation towards the end-product, the software, the finer details of how

data gets originated and stored (as appeared in DFD) is not explicit in Structure Chart. Hence DFD

may still be needed along with Structure Chart to understand the data flow while creating low-level

design.

check the list of properties for transform flow characteristics

be aware that this is a guideline only



Step 2b:

find and mark the center of transformation in the DFD

locate the center of transformation

follow input-driven flows into the center until the data is in an internal format, correct and

complete ===> mark position

trace back output-driven flows to the center until the data is complete and ready for presentation,

but not yet in external format ===> mark position

connect all markings: center of transformation

add data (and control) flows

further decompose (factor) were necessary

user interface handling modules

error-handling modules



add initialisation & termination modules

check quality of design:

cohesion

coupling

reconfirm mapping with DFD

Transaction Analysis

An alternative structured design strategy for developing structure charts is called transaction

analysis.

Transaction analysis is the examination of the DFD to identify processes that represent transaction

centers.

A transaction center is a process that does not do actual transformation upon the incoming data (data

flow); rather, it serves to route the data to two or more processes.

You can think of a transaction center as a traffic cop that directs traffic flow.

Such processes are usually easy to recognize on a DFD, because they usually appear as a process

containing a single incoming data flow to two or more other processes.

TRANSFORM

FUNCTION

A

TRANSFORM

FUNCTION

B

INPUT

FUNCTION

A

INPUT

FUNCTION

D

INPUT

FUNCTION

B

OUTPUT

FUNCTION

A

INPUT

FUNCTION

C

OUTPUT

FUNCTION

C

BOSS

CENTRAL

TRANSFORM

CONTROLLER

OUTPUT

FUNCTION

B

E & F

J & I

J

G & H

E, F, & GI

J

G

I

F

K

E

C



Coupling:

The primary difference between transaction analysis and transform analysis is that

transaction analysis recognizes that modules can be organized around the transaction center rather

than a transform center. Coupling:

TRANSACTION

CENTER

PROCESS

TRANSACTION

TYPE C

PROCESS

TRANSACTION

TYPE B

PROCESS

TRANSACTION

TYPE A

DISPLAY

RESULT

INPUT

FUNCTION

A

BOSS

VALID

TRANSACTION

TRANSACTION

TYPE A, B, OR

C RESULT

TYPE A

RESULT

TRANSACTION

TYPE A

TYPE B

RESULT

TYPE A, B, OR

C RESULT

TRANSACTION

TYPE C

TYPE C

RESULT

TRANSACTION

TYPE B



Types of coupling: (from best to worst)

Data coupling — two modules are said to be data coupled if their dependency is based on the

fact that they communicate by passing of data.

Stamp coupling — two modules are said to be stamp coupled if their communication of data is

in the form of an entire data structure or record.

coupling — two modules are said to be control coupled if their dependency is based on the

fact that they communicate by passing of control information or flags.

Common coupling — modules are said to be common coupled if they refer to the same global

data area.

Content coupling — two modules are said to be content coupled (also referred to as hybrid

coupled) when one module actually modifies the procedural contents of another module.

Cohesion:

Cohesion refers to the degree to which a module's instructions are functionally related.

Highly cohesive modules contain instructions that collectively work together to solve a specific

task.goal is to ensure that modules exhibit a high degree of cohesiveness.

Programs that are implemented with highly cohesive modules tend to be easier to understand, modify,

and maintain. There are seven types or levels of cohesion and they are as follows: (from most

desirable to least desirable)

Functional cohesion — are modules whose instruction are related because they collectively

work together to accomplish a single well-define function.

Sequential cohesion — are modules whose instructions are related because the output data

from one instruction is used as input data to the next instruction.

Communicational cohesion — are modules whose instructions accomplish tasks that utilize

the same piece(s) of data.

Procedural cohesion — are modules whose instructions accomplish different tasks, yet have

been combined because there is a specific order in which the tasks are to be completed.

Temporal cohesion — are modules whose instructions appear to have been grouped together

into a module because of ―time‖.



Logical cohesion — is modules that contain instructions that appear to be related because they fall

into the same logical class of functions.

Coincidental cohesion — is modules that contain instructions that have little or no relationship to one

another.

Normalization:

Normalization is a method for organizing data elements in a database into tables.

Normalization Avoids

Duplication of Data – The same data is listed in multiple lines of the database

Insert Anomaly – A record about an entity cannot be inserted into the table without first

inserting information about another entity – Cannot enter a customer without a sales order

Delete Anomaly – A record cannot be deleted without deleting a record about a related entity.

Cannot delete a sales order without deleting all of the customer‘s information.

Update Anomaly – Cannot update information without changing information in many places.

To update customer information, it must be updated for each sales order the customer has

placed

Normalization is a three stage process – After the first stage, the data is said to be in first

normal form, after the second, it is in second normal form, after the third, it is in third normal form

Before Normalization

Begin with a list of all of the fields that must appear in the database. Think of this as one big

table.

Do not include computed fields

One place to begin getting this information is from a printed document used by the system.

Additional attributes besides those for the entities described on the document can be added to

the database.

Normalization: First Normal Form

Separate Repeating Groups into New Tables.

Repeating Groups Fields that may be repeated several times for one document/entity

Create a new table containing the repeating data



The primary key of the new table (repeating group) is always a composite key; Usually

document number and a field uniquely describing the repeating line, like an item number.

First Normal Form Example

These two tables are a database in first normal form

What if we did not Normalize the Database to First Normal Form?

Repetition of Data – SO Header data repeated for every line in sales order.

Normalization: Second Normal Form

Remove Partial Dependencies.

Functional Dependency The value of one attribute in a table is determined entirely by the

value of another.

Partial Dependency A type of functional dependency where an attribute is functionally

dependent on only part of the primary key (primary key must be a composite key).

Create separate table with the functionally dependent data and the part of the key on which

it depends. Tables created at this step will usually contain descriptions of resources.

Second Normal Form Example

The new table will contain the following fields:

ItemNo, Description

All of these fields except the primary key will be removed from the original table. The primary key

will be left in the original table to allow linking of data:

SalesOrderNo, ItemNo, Qty, UnitPrice

Never treat price as dependent on item. Price may be different for different sales orders (discounts,

special customers, etc.)

Along with the unchanged table below, these tables make up a database in second normal form:

SalesOrderNo, Date, CustomerNo, CustomerName, CustomerAdd, ClerkNo, ClerkName

What if we did not Normalize the Database to Second Normal Form?

Repetition of Data – Description would appear every time we had an order for the item

Delete Anomalies – All information about inventory items is stored in the SalesOrderDetail

table. Delete a sales order, delete the item.

Insert Anomalies – To insert an inventory item, must insert sales order.

Update Anomalies – To change the description, must change it on every SO.



Normalization: Third Normal Form

Remove transitive dependencies.

Transitive Dependency A type of functional dependency where an attribute is functionally

dependent on an attribute other than the primary key. Thus its value is only indirectly

determined by the primary key.

Create a separate table containing the attribute and the fields that are functionally dependent

on it. Tables created at this step will usually contain descriptions of either resources or agents.

Keep a copy of the key attribute in the original file.

Third Normal Form Example

The new tables would be:

CustomerNo, CustomerName, CustomerAdd

ClerkNo, ClerkName

All of these fields except the primary key will be removed from the original table. The

primary key will be left in the original table to allow linking of data as follows:

SalesOrderNo, Date, CustomerNo, ClerkNo

Together with the unchanged tables below, these tables make up the database in third normal

form.

ItemNo, Description

SalesOrderNo, ItemNo, Qty, UnitPrice

What if we did not Normalize the Database to Third Normal Form?

Repetition of Data – Detail for Cust/Clerk would appear on every SO

Delete Anomalies – Delete a sales order, delete the customer/clerk

Insert Anomalies – To insert a customer/clerk, must insert sales order.

Update Anomalies – To change the name/address, etc, must change it on every SO.

Completed Tables in Third Normal Form

Customers: CustomerNo, CustomerName, CustomerAdd

Clerks: ClerkNo, ClerkName

Inventory Items: ItemNo, Description

Sales Orders: SalesOrderNo, Date, CustomerNo, ClerkNo

SalesOrderDetail: SalesOrderNo, ItemNo, Qty, UnitPrice



UNIT III

3.1 Object-oriented systems

An object-oriented system is composed of objects. The behavior of the system results from the

collaboration of those objects. Collaboration between objects involves them sending messages to

each other. Sending a message differs from calling a function in that when a target object receives

a message, it itself decides what function to carry out to service that message. The same message

may be implemented by many different functions, the one selected depending on the state of the

target object.

The implementation of "message sending" varies depending on the architecture of the system

being modeled, and the location of the objects being communicated with.

Object-oriented analysis

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a

conceptual model of the information that exists in the area being analyzed. Analysis models do

not consider any implementation constraints that might exist, such as concurrency, distribution,

persistence, or how the system is to be built. Implementation constraints are dealt during object-

oriented design (OOD). Analysis is done before the Design[citation needed].

The sources for the analysis can be a written requirements statement, a formal vision document,

interviews with stakeholders or other interested parties. A system may be divided into multiple

domains, representing different business, technological, or other areas of interest, each of which

are analyzed separately.

The result of object-oriented analysis is a description of what the system is functionally required

to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one

or more UML class diagrams, and a number of interaction diagrams. It may also include some

kind of user interface mock-up. The purpose of object oriented analysis is to develop a model that

describes computer software as it works to satisfy a set of customer defined requirements.

Object-oriented design

Object-oriented design (OOD) transforms the conceptual model produced in object-oriented

analysis to take account of the constraints imposed by the chosen architecture and any non-



functional – technological or environmental – constraints, such as transaction throughput,

response time, run-time platform, development environment, or programming language.

The concepts in the analysis model are mapped onto implementation classes and interfaces. The

result is a model of the solution domain, a detailed description of how the system is to be built.

3.2 UML

Unified Modelling Language (UML) is the set of notations,models and diagrams used when

developing object-oriented (OO) systems. UML is the industry standard OO visual modelling

language.

The latest version is UML 1.4 and was formed from the coming together of three leading software

methodologists; Booch, Jacobson and Rumbaugh. UML allows the analyst ways of describing

structure, behaviour of significant parts of system and their relationships.

Unified Modeling Language (UML)

It is a standardized general-purpose modeling language in the field of software engineering. The

standard is managed, and was created by, the Object Management Group. UML includes a set of

graphic notation techniques to create visual models of software-intensive systems.

The Unified Modeling Language is commonly used to visualize and construct systems which are

software intensive. A special language called Systems Modeling Language was designed to

handle systems which were defined within UML 2.0.

The Unified Modeling Language is important for a number of reasons. First, it has been used as a

catalyst for the advancement of technologies which are model driven, and some of these include

Model Driven Development and Model Driven Architecture. Because an emphasis has been

placed on the importance of graphics notation, UML is proficient in meeting this demand, and it

can be used to represent behaviors, classes, and aggregation. While software developers were

forced to deal with more rudimentary issues in the past, languages like UML have now allowed

them to focus on the structure and design of their software programs. It should also be noted that

UML models can be transformed into various other representations, often without a great deal of

effort. One example of this is the ability to transform UML models into Java representations.



This transformation can be accomplished through a transformation language that is similar to

QVT. Many of these languages may be supported by OMG. The Unified Modeling Language has

a number of features and characteristics which separate it from other languages within the same

category. Many of these attributes have allowed it to be useful for developers. In this article, I

intend to show you many of these attributes, and you will then understand why the Unified

Modeling Language is one of the most powerful languages in existence today.

Unified Process

The Unified Software Development Process or Unified Process is a popular iterative and

incremental software development process framework. The best-known and extensively

documented refinement of the Unified Process is the Rational Unified Process (RUP).

Profile of a typical project showing the relative sizes of the four phases of the Unified Process.

Overview

The Unified Process is not simply a process, but rather an extensible framework which should be

customized for specific organizations or projects. The Rational Unified Process is, similarly, a

customizable framework. As a result it is often impossible to say whether a refinement of the

process was derived from UP or from RUP, and so the names tend to be used interchangeably.

The name Unified Process as opposed to Rational Unified Process is generally used to describe

the generic process, including those elements which are common to most refinements. The

Unified Process name is also used to avoid potential issues of trademark infringement since

Rational Unified Process and RUP are trademarks of IBM. The first book to describe the process

was titled The Unified Software Development Process and published in 1999 by Ivar Jacobson,

Grady Booch and James Rumbaugh. Since then various authors unaffiliated with Rational

Software have published books and articles using the name Unified Process, whereas authors

affiliated with Rational Software have favored the name Rational Unified Process.

Unified Process Characteristics

Iterative and Incremental

The Unified Process is an iterative and incremental development process. The Elaboration,

Construction and Transition phases are divided into a series of timeboxed iterations. (The

Inception phase may also be divided into iterations for a large project.) Each iteration results in an



increment, which is a release of the system that contains added or improved functionality

compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g. Requirements,

Design, Implementation, Testing) the relative effort and emphasis will change over the course of

the project.

3.3 Use Case

In the Unified Process, use cases are used to capture the functional requirements and to define the

contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all

the way through implementation, test and deployment.

Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape

the system. Since no single model is sufficient to cover all aspects of a system, the Unified

Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline

which is created during the Elaboration phase. This partial implementation of the system serves

and validate the architecture and act as a foundation for remaining development.

Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early

in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase,

must be selected in order to ensure that the greatest risks are addressed first.

Project Lifecycle

The Unified Process divides the project into four phases:

Inception

Elaboration

Construction

Transition



Inception Phase

Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception

Phase is long then it may be an indication of excessive up-front specification, which is contrary to the

spirit of the Unified Process.

The following are typical goals for the Inception phase.

Establish a justification or business case for the project

Establish the project scope and boundary conditions

Outline the use cases and key requirements that will drive the design tradeoffs

Outline one or more candidate architectures

Identify risks

Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.

Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy majority of the

system requirements. However, the primary goals of Elaboration are to address known risk factors

and to establish and validate the system architecture. Common processes undertaken in this phase

include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic

notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable Architecture

Baseline. This is a partial implementation of the system which includes the core, most

architecturally significant, components. It is built in a series of small, timeboxed iterations. By the

end of the Elaboration phase the system architecture must have stabilized and the executable

architecture baseline must demonstrate that the architecture will support the key system

functionality and exhibit the right behavior in terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the

Construction phase. At this point the plan should be accurate and credible, since it should be

based on the Elaboration phase experience and since significant risk factors should have been

addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.



Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the system is built

on the foundation laid in Elaboration. System features are implemented in a series of short,

timeboxed iterations. Each iteration results in an executable release of the software. It is

customary to write full text use cases during the construction phase and each one becomes the

start of a new iteration. Common UML (Unified Modelling Language) diagrams used during this

phase include Activity, Sequence, Collaboration, State (Transition) and Interaction Overview

diagrams. The Initial Operational Capability Milestone marks the end of the Construction phase.

s. Normally this phase would take between two to six weeks for large projects and may be only a

few days for smaller projects. The following should be done during this phase:

1. Project idea is developed.

2. Assess the capablilities of any current system that provides similar functionality to the new project

even if the current system is a manual system. This will help determine cost savings that the new

system can provide.

3. Utilize as many users and potential users as possible along with technical staff, customers, and

management to determine desired system features, functional capabilities, and performance

requirements. Analyze the scope of the proposed system.

4. Identify feature and functional priorities along with preliminary risk assessment of each system

feature or function.

5. Identify systems and people the system will interact with.

6. For large systems, break the system down into subsystems if possible.

7. Identify all major use cases and describe significant use cases. No need to make expanded use

cases at this time. This is just to help identify and present system functionality.

8. Develop a throw away prototype of the system with breadth and not depth. This prototype will

address some of the greatest technical risks. The time to develop this prototype should be specifically

limited. For a project that will take about one year, the prototype should take one month.

9. Present a business case for the project (white paper) identifying rough cost and value of the

project. The white paper is optional for smaller projects. Define goals, estimate risks, and resources

required to complete the project.



10. Set up some major project milestones (mainly for the elaboration phase). A rough estimate of the

overall project size is made.

11. Preliminary determination of iterations and requirements for each iteration. This outlines system

functions and features to be included in each iteration. Keep in mind that this plan will likely be

changes as risks are further assessed and more requirements are determined.

12. Management Approval for a more serious evaluation of the project.

13. This phase is done once the business case is presented with major milestones determined (not cast

in stone yet) and management approves the plan. At this point the following should be complete:

- Business case (if required) with risk assessment.

- Preliminary project plan with preliminary iterations planned.

- Core project requirements are defined on paper.

- Major use cases are defined.

The inception phase has only one iteration. All other phases may have multiple iterations.

The overriding goal of the inception phase is to achieve concurrence among all stakeholders on

the lifecycle objectives for the project. The inception phase is of significance primarily for new

development efforts, in which there are significant business and requirements risks which must be

addressed before the project can proceed. For projects focused on enhancements to an existing

system, the inception phase is more brief, but is still focused on ensuring that the project is both

worth doing and possible to do.

Objectives

The primary objectives of the Inception phase include:

Establishing the project's software scope and boundary conditions, including an operational

vision, acceptance criteria and what is intended to be in the product and what is not.

Discriminating the critical use cases of the system, the primary scenarios of operation that will

drive the major design tradeoffs.

Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the

primary scenarios

Estimating the overall cost and schedule for the entire project (and more detailed estimates for the

elaboration phase that will immediately follow)

Estimating potential risks (the sources of unpredictability)

Preparing the supporting environment for the project.



Essential Activities

The essential activities of the Inception include:

1. Formulating the scope of the project.

This involves capturing the context and the most important requirements and constraints to such

an extent that you can derive acceptance criteria for the end product.

2. Planning and preparing a business case.

Evaluating alternatives for risk management, staffing, project plan, and cost/schedule/profitability

tradeoffs.

3. Synthesizing a candidate architecture

Evaluating tradeoffs in design, and in make/buy/reuse, so that cost, schedule and resources can be

estimated. The aim here is to demonstrate feasibility through some kind of proof of concept. This

may take the form of a model which simulates what is required, or an initial prototype which

explores what are considered to be the areas of high risk. The prototyping effort during inception

should be limited to gaining confidence that a solution is possible - the solution is realized during

elaboration and construction.

4. Preparing the environment for the project

Assessing the project and the organization, selecting tools, deciding which parts of the process to

improve.

Milestone

The Lifecycle Objectives Milestone evaluates the basic viability of the project.

Tailoring Decisions

The example iteration workflow shown at the top of this page represents a typical Inception

iteration in medium sized projects. The Sample Iteration Plan for Inception represents a different

perspective of the breakdown of activities to undertake in an Inception iteration. This iteration

plan is more complete in terms of workflow details and activities, and as such, more suitable for

large projects. Small projects might decide to do only a subset of these workflow details,

deviations should be challenged and documented as part of the project-specific process.

Inception Phase includes:

Refining the scope of the project

Project planning



Risk identification and analysis

Preparing the project environment

Estimating the Budget

The Use Case Model

The Use Case Model describes the proposed functionality of the new system. A Use Case

represents a discrete unit of interaction between a user (human or machine) and the system. A Use

Case is a single unit of meaningful work; for example login to system, register with system and

create order are all Use Cases. Each Use Case has a description which describes the functionality

that will be built in the proposed system. A Use Case may 'include' another Use Case's

functionality or 'extend' another Use Case with its own behaviour.

Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts

with the system to perform meaningful work

A Use Case description will generally include:

1. General comments and notes describing the use case.

2. Requirements

3. Constraints

4. Scenarios

5. Scenario diagram

Actors

An Actor is a user of the system. This includes both human users and other computer systems. An

Actor uses a Use Case to perform some piece of work which is of value to the business. The set of



Use Cases an actor has access to defines their overall role in the system and the scope of their

action.

Constraints, Requirements and Scenarios

The formal specification of a Use Case includes:

1. Requirements. These are the formal functional requirements that a Use Case must provide to

the end user. They correspond to the functional specifications found in structured methodologies.

A requirement is a contract that the Use Case will perform some action or provide some value to

the system.

2. Constraints. These are the formal rules and limitations that a Use Case operates under, and

includes pre- post- and invariant conditions. A pre-condition specifies what must have already

occurred or be in place before the Use Case may start. A post-condition documents what will be

true once the Use Case is complete. An invariant specifies what will be true throughout the time

the Use Case operates.

3. Scenarios. Scenarios are formal descriptions of the flow of events that occurs during a Use Case

instance. These are usually described in text and correspond to a textual representation of the

Sequence Diagram.

3.4 Overview of Diagrams: Collaboration-Sequence, Class

One Use Case may include the functionality of another as part of its normal processing.

Generally, it is assumed that the included Use Case will be called every time the basic path is

run. An example may be to list a set of customer orders to choose from before modifying a

selected order - in this case the <list orders> Use Case may be included every time the

<modify order> Use Case is run.

A Use Case may be included by one or more Use Cases, so it helps to reduce duplication of

functionality by factoring out common behaviour into Use Cases that are re-used many times.



One Use Case may extend the behaviour of another - typically when exceptional

circumstances are encountered. For example, if before modifying a particular type of customer

order, a user must get approval from some higher authority, then the <get approval> Use Case

may optionally extend the regular <modify order> Use Case.

Sequence Diagrams

UML provides a graphical means of depicting object interactions over time in Sequence

Diagrams. These typically show a user or actor, and the objects and components they interact

with in the execution of a use case. One sequence diagram typically represents a single Use

Case 'scenario' or flow of events.

Sequence diagrams are an excellent way to document usage scenarios and to both capture

required objects early in analysis and to verify object usage later in design. Sequence diagrams

show the flow of messages from one object to another, and as such correspond to the methods

and events supported by a class/object.

The diagram illustrated below shows an example of a sequence diagram, with the user or actor

on the left initiating a flow of events and messages that correspond to the Use Case scenario.

The messages that pass between objects will become class operations in the final model.



Implementation Diagram

A Use Case is a formal description of functionality the system will have when constructed. An

implementation diagram is typically associated with a Use Case to document what design elements

(eg. components and classes) will implement the Use Case functionality in the new system. This

provides a high level of traceability for the system designer, the customer and the team that will

actually build the system. The list of Use Cases that a component or class is linked to documents the

minimum functionality that must be implemented by the component.

Relationships Between Use Cases

Use cases could be organized using following relationships:

1. Generalization

2. Association

3. Extend

4. Include

Generalization Between Use Cases

Generalization between use cases is similar to generalization between classes – child use case

inherits properties and behavior of the parent use case and may override the behavior of the

parent.

Notation:

Generalization is rendered as a solid directed line with a large open arrowhead (same as

generalization between classes).

Generalization between use cases

Association Between Use Cases

Use cases can only be involved in binary Associations. Two use cases specifying the same subject

cannot be associated since each of them individually describes a complete usage of the system.



Extend Relationship

Extend is a directed relationship from an extending use case to an extended use case that

specifies how and when the behavior defined in usually supplementary (optional) extending use

case can be inserted into the behavior defined in the use case to be extended.

Note: Extended use case is meaningful on its own, independently of the extending use case,

while the extending use case typically defines behavior that is not necessarily meaningful by

itself.

The extension takes place at one or more extension points defined in the extended use case.

The extend relationship is owned by the extending use case. The same extending use case can

extend more than one use case, and extending use case may itself be extended.

Extend relationship between use cases is shown by a dashed arrow with an open arrowhead from

the extending use case to the extended (base) use case. The arrow is labeled with the keyword

«extend».

Registration use case is meaningful on its own, and it could be extended with optional Get Help

On Registration use case

The condition of the extend relationship as well as the references to the extension points are

optionally shown in a Note attached to the corresponding extend relationship.

Registration use case is conditionally extended by Get Help On Registration use case in extension

point Registration Help

Extension Point

An extension point is a feature of a use case which identifies (references) a point in the behavior

of the use case where that behavior can be extended by some other (extending) use case, as

specified by an extend relationship.



Extension points may be shown in a compartment of the use case oval symbol under the heading

extension points. Each extension point must have a name, unique within a use case. Extension

points are shown as text string according to the syntax: <extension point> ::= <name> [:

<explanation>]

The optional description is given usually as informal text, but can also be given in other forms,

such as the name of a state in a state machine, an activity in an activity diagram, a precondition, or

a postcondition.

Registration use case with extension points Registration Help and User Agreement

Extension points may be shown in a compartment of the use case rectangle with ellipse icon

under the heading extension points.

Extension points of the Registration use case shown using the rectangle notation

Include Relationship

An include relationship is a directed relationship between two use cases, implying that the

behavior of the required (not optional) included use case is inserted into the behavior of the

including (base) use case. Including use case depends on the addition of the included use case.

The include relationship is intended to be used when there are common parts of the behavior of

two or more use cases. This common part is extracted into a separate use case to be included by

all the base use cases having this part in common.

Execution of the included use case is analogous to a subroutine call or macro command in

programming. All of the behavior of the included use case is executed at a single location in the

including use case before execution of the including use case is resumed.



As the primary use of the include relationship is to reuse common parts, including use cases are

usually not complete by themselves but dependent on the included use cases.

Include relationship between use cases is shown by a dashed arrow with an open arrowhead from

the including (base) use case to the included (common part) use case. The arrow is labeled with

the keyword «include».

Four Phases of Unified Process

The Unified Process consists of cycles that may repeat over the long-term life of a system. A

cycle consists of four phases: Inception, Elaboration, Construction and Transition. Each cycle is

concluded with a release, there are also releases within a cycle. Let's briefly review the four

phases in a cycle:

Inception Phase - During the inception phase the core idea is developed into a product vision. In

this phase, we review and confirm our understanding of the core business drivers. We want to

understand the business case for why the project should be attempted. The inception phase

establishes the product feasibility and delimits the project scope.

Elaboration Phase - During the elaboration phase the majority of the Use Cases are specified in

detail and the system architecture is designed. This phase focuses on the "Do-Ability" of the

project. We identify significant risks and prepare a schedule, staff and cost profile for the entire

project.

Construction Phase - During the construction phase the product is moved from the architectural

baseline to a system complete enough to transition to the user community. The

architectural baseline grows to become the completed system as the design is refined into code.

Transition Phase - In the transition phase the goal is to ensure that the requirements have been

met to the satisfaction of the stakeholders. This phase is often initiated with a beta release of the

application. Other activities include site preparation, manual completion, and defect identification

and correction. The transition phase ends with a postmortem devoted to learning and recording

lessons for future cycles.



The primary purpose of this phase is to complete the most essential parts of the project that are

high risk and plan the construction phase. This is the part of the project where technical risk is fully

evaluated and/or eliminated by building the highest risk parts of the project. During this phase

personnel requirements should be more accurately determined along with estimated man hours to

complete the project.

The complete cost and time frame of the project is more firmly determined. During this

phase how the system will work must be considered. Use cases will help identify risks. Steps to take

during this phase:

1. Complete project plan with construction iterations planned with requirements for each iteration.

2. 80% of use cases are completed. Significant use cases are described in detail.

3. The project domain model is defined. (Don't get bogged down)

4. Rank use cases by priority and risk. Do the highest priority and highest risk use cases first. Items

that may be high risk:

-Overall system architecture especially when dealing with communication between

subsystems.

-Team structure.

-Anything not done before or used before such as a new programming language, or using the

unified/iterative process for the first time.

5. Begin design and development of the riskiest and highest priority use cases. There will be an

iteration for each high risk and priority use case.

6. Plan the iterations for the construction phase. This involves choosing the length of the iterations

and deciding which use cases or parts of use cases will be implemented during each iteration.

Develop the higher priority and risk use cases during the first iterations in the construction phase.

As was done on a preliminary level in the previous phase, the value (priority) of use cases and

their respective risks must be more fully assessed in this phase. This may be done be either

assigning an number to each use case for both value and risk. or categorize them by high,

medium, or low value and risk. Time required for each use case should be estimated to the man

week. Do the highest priority and highest risk use cases first.

Requirements to be completed for this phase include:



1. Description of the software architecture. Therefore most use cases should be done, activity

diagrams, state charts, system sequence diagrams, and the domain model should be mostly

complete.

2. A prototype that overcomes the greatest project technical risk and has minimal high priority

functionality.

3. Complete project plan.

4. Development plan.

There may be an elaboration phase for each high risk use case.

Considering the various diagrams and charts to be created, when they are created, and the best

order to create them in, there seems to be a variety of opinions. This is because in the real

world there may be more than one correct solution and there are no hard and fast rules that

work everytime. In a way, this flexibility is a strength of UML.

Some documentation indicates that most use cases should be done before creating a domain

model and others indicate that the domain model can be built on a use case by use case basis.

A good compromise is to spend a short time on a brief domain model during the elaboration

phase, then enhance the domain model as each use case is developed during the elaboration

and construction phase iterations.

Some documentation indicates that activity diagrams and class diagrams should be complete

before the domain model is done. It is possible to create some of the diagrams and charts

(artifacts) in parallel with each otherCompletion of 80% of use case diagrams.

1. Completion of 80% of high level use case diagrams.

2. Completion of expanded use case diagrams for major use cases only.

3. System sequence diagrams for major use cases.

4. Domain model (Don't get bogged down here with details). Just get a good idea of concepts

involved. Use use cases to create the domain model. Any use case that strongly impacts the

domain model should be considered and concepts from that use case should be incorporated in

the domain model. The initial domain model may be drawn without lines and attributes to

avoid too much detail and determine important use cases. The domain model may be refined

later as the project analysis continues. If the system is large, domain models should be done on

a per use case basis.

5. Optionally create a glossary of terms for concepts to improve team communication.



After this point the design part of the project begins (although more analysis is done for each

use case) and the following will be done in each iteration of the elaboration and construction

phases.

1. Operation contracts based on domain model and use cases.

2. Collaboration diagrams.

3. Class diagrams.

4. Map class and collaboration diagrams to code.

5. Update the domain model but do not force it to the class diagrams.

Considerations during this project should be the following:

Consider possible significant changes (down the road) to the system during analysis.

Regarding system functional ability what do you expect to be able to change?

Elaboration phase plans the necessary activities and required resources and specifies the

features and designing the architecture.

Things to do: With the input of the use case model generated from the previous phase, we

transform it into a design model via an analysis model. In brief, both an analysis model and a

design model are structures made up of classifiers and a set of use-case realizations that

describe how this structure realizes the use cases. Classifiers are, in general, "class-like"

things.

The analysis model is a detailed specification of the requirements and works as a first cut at a

design model, although it is a model of its own. It is used by developers to understand

precisely the use cases as described in the requirements. The analysis model is different from

the design model in that it is a conceptual model rather than a blueprint of the implementation.

Class Diagrams

Sequence Diagrams

Collaboration Diagrams

Exit Criteria:

A detailed software development plan, containing:

1. An updated risk assessment,

2. A management plan,

3. A staffing plan,



4. A phase plan showing the number and contents of the iteration

5. An iterative plan, detailing the next iteration

6. The development environment and other tools required

7. A test plan

A baseline vision, in the form of a set of evalution criteria for the final product

Objective, measurable evalution criteria for assessing the results of the initial iterations of the

construction phase

A domain analysis model (80% complete), sufficient to be able to call the corresponding

architecture 'complete'.

A software architecture description (stating constraints and limitations)

An executable architectural baseline.

During the Elaboration phase the project team is expected to capture a healthy majority of the

system requirements. However, the primary goals of Elaboration are to address known risk factors

and to establish and validate the system architecture. Common processes undertaken in this phase

include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic

notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable Architecture

Baseline. This is a partial implementation of the system which includes the core, most

architecturally significant, components. It is built in a series of small, timeboxed iterations. By the

end of the Elaboration phase the system architecture must have stabilized and the executable

architecture baseline must demonstrate that the architecture will support the key system

functionality and exhibit the right behavior in terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the

Construction phase. At this point the plan should be accurate and credible, since it should be

based on the Elaboration phase experience and since significant risk factors should have been

addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

2.2 Domain Model

A domain model, or Domain Object Model (DOM) in problem solving and software engineering

can be thought of as a conceptual model of a domain of interest (often referred to as a problem



domain) which describes the various entities, their attributes and relationships, plus the constraints

that govern the integrity of the model elements comprising that problem domain.

2.2.1 Overview

The domain model is created in order to represent the vocabulary and key concepts of the problem

domain. The domain model also identifies the relationships among all the entities within the scope of

the problem domain, and commonly identifies their attributes. A domain model that encapsulates

methods within the entities is more properly associated with object oriented models. The domain

model provides a structural view of the domain that can be complemented by other dynamic views,

such as Use Case models.

An important benefit of a domain model is that it describes and constrains the scope of the problem

domain. The domain model can be effectively used to verify and validate the understanding of the

problem domain among various stakeholders. It is especially helpful as a communication tool and a

focusing point both amongst the different members of the business team as well as between the

technical and business teams.

2.2.2 Usage

A well-thought domain model serves as a clear depiction of the conceptual fabric of the problem

domain and therefore is invaluable to ensure all stakeholders are aligned in the scope and meaning of

the concepts indigenous to the problem domain. A high fidelity domain model can also serve as an

essential input to solution implementation within a software development cycle since the model

elements comprising the problem domain can serve as key inputs to code construction, whether that

construction is achieved manually or through automated code generation approaches. It is important,

however, not to compromise the richness and clarity of the business meaning depicted in the domain

model by expressing it directly in a form influenced by design or implementation concerns.

The domain model is one of the central artifacts in the project development approach called Feature

Driven Development (FDD).

In UML, a class diagram is used to represent the domain model. In Domain-driven design, the domain

model (Entities and Value objects) is a part of the Domain layer which often also includes other

concepts such as Services.

Sample domain model for a health insurance plan



In this simplified example, the Auction Manager object represents a Business Worker role that will

likely be performed by the online auction management system itself. The Auction and Auction Item

objects are Business Entities that are used or produced by the Auction Manager worker acting as an

agent for the Seller and Buyer Business Actors. From a database design perspective, the Auction and

Auction Item Business Entities are candidate entities for the Conceptual Data Model.

Requirements and Analysis Models

For projects that do not perform business modeling, the Requirements (System Use Case) and

Analysis Models contain model elements that can be used to develop an initial Conceptual Data

Model. For projects that use business modeling, the business entities and relationships identified in

the Business Analysis Models are refined and detailed in the Analysis Model as Entity Classes.

System Use-Case Model

The System Use-Case Model contains System Actors and System Use Cases that define the primary

interactions of the users with the system. The System Use Cases define the functional requirements

for the system.



From a conceptual data modeling perspective, the System Actors represent entities external to the

system for which the system might need to store persistent information. This is important in cases

where the System Actor is an external system that provides data to and/or receives data from the

system under development. System Actors can be derived from the Business Actors in the Business

Use-Case Model and the Business Workers in the Business Analysis Model.

The figure below depicts the Business Use-Case Model for the online auction system. In this model,

the Buyer and Seller Business Actors are now derived from a generic User Business Actor. A new

System Actor named Credit Service Bureau has been added to reflect the need to process payments

through an external entity. This new System Actor is another candidate entity for the Conceptual Data

Model.

Analysis Model

The Analysis Model contains the Analysis Classes identified in the Use-Case Realizations for the

System Use Cases. The types of Analysis Classes that are of primary interest from a conceptual data

modeling perspective are the Entity Analysis Classes. As defined in Guidelines: Analysis Class,



Entity Analysis Classes represent information managed by the system that must be stored in a

persistent manner. The Entity Analysis Classes and their relationships form the basis of the initial

Data Model for the application.

The conceptual Entity Analysis Classes in the Analysis Model might be refined and detailed into

logical Persistent Design Classes in the Design Model. These design classes represent candidate

tables in the Data Model. The attributes of the classes are candidate columns for the tables and also

represent candidate keys for them. See Guidelines: Forward-Engineering Relational Databases for a

description of how elements in the Design Model can be mapped to Data Model elements.

Conceptual Class Category List

A conceptual class is a real-world concept or thing; a conceptual or essential perspective. At the noun

filtering stage we are looking for conceptual classes. As we move through the design process we will

start to design software classes that represent an implementation perspective of a software component

but we will not get into language specific classes in 466. A conceptual class is not an implementation

class, such as a class that can be implemented in an OO language such as Java or C++

Conceptual Class Category

Examples

Physical or tangible objects

Register, Airplane

Specifications, deigns or descriptions of things

ProductSpecification FlightDescription

Places

Store Airport

Transactions

Sale payment Reservation

Transaction line items

SalesLineItem

Roles of people

Cashier Pilot

Containers of other things Store Bin Airplane

Things in a container

Item Passenger



Other computer or electro-mechanical systems

external to the system

CreditPaymentAuthorizationSystem

AirTrafficControl

Organizations

SalesDepartment ObjectAirline

Events

Sale Payment Meeting

Maintenance and Metrics

During use case realization, we identify mainly four "types" of classes, boundary classes, data

store classes and control classes.

The entity classes represent the information that the system uses. Examples of entity classes are:

Customer, Product, and Supplier. Entity classes are essential to the system as the expected

functionality of the system includes maintaining information about them or retrieving information

from them.

The boundary classes represent the interaction between the system and its actors. A GUI form is

an example of a boundary class.

Data store classes encapsulate the design decisions about data storage and retrieval strategies. This

provides us flexibility to move a n application from database platform to another.

The control classes represent the control logic of the system. They implement the flow of events

as given in a use case.

Entity Classes

Entity classes are the abstractions of the keys concepts of the system being modelled. If the steps

of the Architectural Analysis have been carried out, many of the entity classes may have already

been identified during those steps.

The Core functionality and logic of the system are encapsulated in the various entity classes. For

example, if interest is to be calculated and paid to savings account holders, a savings Account

entity class may be responsible for computing and returning the interest.

You can normally look for the following types of things as potential entity classes:



1. Roles played by people or organizations about which information is required to be maintained by

the system. For Example, Student in a Library Management System, Vendor in a Purchase

Ordering System.

2. Other physical, tangible things. For example, Book in a Library Management System.

3. Events that requires remembrance. For example, Reservation and Issue in a Library Management

System.

The logical data structures (attributes and relationships) of the entity classes would be designed to

hold and manipulate the data according to the system's requirements. Values of the attributes and

their relationships of the entity class objects are often given by actors. The entity classes are

responsible for storing and managing information in the system.

Entity class objects are usually persistent, having attributes and relationships that need to be

retained for a long time, sometimes even before the life of system. An entity class is usually not

specific to one use cause realization. Objects of most entity classes would required in multiple use

cases. Sometimes, an entity object may not be specific to the system itself.

Boundary Classes

Boundary classes represent the interaction between the system and its actors. They insulate the

system from changes in the surroundings of the system, such as user interfaces, and interfaces to

other systems.

There may be various types of boundary classes in a system:

1. User Interfaces classes: Classes for encapsulating the human user interface of the system, such as

GUI forms.

2. System Interface Classes: Classes that encapsulate the interaction of the system with other

systems.

3. Device Interface Classes: Classes that provide the interface to devices that detect external events.

An important objective of identifying boundary classes is to ensure that the entity classes and the

control classes are not affected by any changes to the boundary classes.

Actors interact with the system only through the boundary classes.

User Interface Classes

A user interface class represents the interaction between a use case and its initiating actor.

This class has the responsibility of coordinating the interaction with the actor. A boundary



class may have various subsidiary classes to which some of its responsibilities are delegated.

For example, in a GUI application, there may be multiple forms within a use case.

During use case analysis, you should use the boundary classes as just place-holders for the GUI

forms. Detailed GUI design is an activity of Class Design. During Analysis, the emphasis should

be only on isolating all environment-dependent behaviour as boundary classes. These classes will

get refined or replaced in the later stages.

System Interface Classes

A system interface class is responsible for interfacing with an external system. The interface

offered by the external system would have been identified by the developers of that system. Thus,

the behaviour of a system interface class should be derived directly from the interface

specifications of the external system.

System interface classes achieve the purpose of isolating the internal details of the external

systems, which may change over a period of time. Our system should not get affected by such

changes in the internal details of the external systems.

Device Interface Classes

Device interface classes are responsible for interacting with the external devices that the system

may depend upon for receiving inputs or handling outputs. Examples of such external devices

would be: bar code reader, system clock, printer, etc.

A device may already have a well-defined interface, which could be used by you later during

design. Therefore, a note of such interface should be made in the model documentation.

Data Store Classes

Data Store classes encapsulate our design decisions about the database structures which are used

to store entity class objects, and to retrieve them later. For each entity class that required

persistence, we create a corresponding data store class. A data store class typically receives an

object of an entity class, and make it persistence (for example, by inserting a row in a table). At a

later point of time, we may ask the data store class to return the entity class object.

Encapsulating the database design designs in data store classes, makes the entity classes

independent of the database structure, and thus provides us greater flexibility to move an

application from one database platform to another.



Controller Classes

Controller classes provide co-ordinating behaviour in the system. A typical example would be a

controller class implementing the logic and flow of events of a use case.

Controller Classes isolates the entity classes and boundary classes from each other, making the

system independent of the changes to the system boundary. They also isolate the use case specific

behaviour from the entity class objects, thus making them re-usable across use cases and even

across systems.

Simple use cases may be performed without using controller classes, with direct flow of data

between boundary objects and entity objects. However, more complex use cases usually require

and benefit from such controller classes. The characteristics of controller classes are:

1. They define the order of events and transactions within a use case. In other words, they

encapsulate the use case-specific behaviour of the system.

2. They are relatively independent of the changes to the internal structure or behaviour of the entity

classes.

3. They are nearly independent of changes to the boundary classes.

4. They may use or set several entity classes, thus coordinating the behaviour of these entity classes.

However, this coordination can be invisible to the participating entity classes.

Though most of the times a control class correspond to a single use case, some times a single

controller class may be use to control several use cases. Some tines there may even be multiple

controller classes with in a single use case. As mentioned earlier, there may be use cases that do

not require controller classes.

Association:

Association defines the relationship between two or more classes in the System. These generally

relates to the one object having instance or reference of another object inside it. This article

discusses on how we can implement Association in UML.

Associations in UML can be implemented using following ways:

1.Multiplicity

2.Aggregation

3.Composition



Multiplicity in UML: Multiplicity indicates the no of instance of one class is linked to one

instance of another class. The various multiplicity values are listed below:

Attributes

It is a logical data value of an object

In UML:

1. Attributes are shown in the second compartment of the class box.

2. The type of an attribute may optionally be shown.

In a domain model, attributes and data types should be simple. Complex concepts should be

represented by an association to another conceptual class.

An attribute should be what the UML standard calls a data type: a set of values for which unique

identity is not meaningful. Numbers, strings, Booleans, dates, times, phone numbers, and

addresses are examples of data types. Values of these types are called value objects.

Relating Types

Conceptual classes in a domain model should be related by associations, not attributes.

In particular, an attribute should not be used as a kind of foreign key.



Quantities and Units

Quantities with associated units should be represented either as conceptual classes or as attributes of

specialized types that imply units (e.g., Money or Weight).

Derived Attributes

A quantity that can be calculated from other values, such as role multiplicities, is a derived attribute,

designated in UML by a leading slash symbol.

NextGen POS Domain Model Attributes



Strategies to Identify Conceptual Classes

Two techniques are presented in the following sections:

1. Use a conceptual class category list.

2. Identify noun phrases.

Another excellent technique for domain modeling is the use of analysis patterns, which are

existing partial domain models created by experts

Finding Conceptual Classes with Noun Phrase Identification

Another useful technique (because of its simplicity) suggested in [Abbot83] is linguistic

analysis: identify the nouns and noun phrases in textual descriptions of a domain, and consider

them as candidate conceptual classes or attributes.

Care must be applied with this method; a mechanical noun-to-class mapping isn't possible,

and words in natural languages are ambiguous. Nevertheless, it is another source of

inspiration. The fully dressed use cases are an excellent description to draw from for this

analysis. For example, the current scenario of the Process Sale use case can be used.

Main Success Scenario (or Basic Flow):

1. Customer arrives at a POS checkout with goods and/or services to purchase.

2. Cashier starts a new sale.

3. Cashier enters item identifier.

4. System records sale line item and presents item description, price, and running total. Price

calculated from a set of price rules. Cashier repeats steps 2-3 until indicates done.

5. System presents total with taxes calculated.

6. Cashier tells Customer the total, and asks for payment.

7. Customer pays and System handles payment.

8. System logs the completed sale and sends sale and payment information to the external

Accounting (for accounting and commissions) and Inventory systems (to update inventory).

9. System presents receipt.

10. 10.Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows):

7a. Paying by cash:

1. Cashier enters the cash amount tendered.



2. System presents the balance due, and releases the cash drawer.

3. Cashier deposits cash tendered and returns balance in cash to Customer.

4. System records the cash payment.

The domain model is a visualization of noteworthy domain concepts and vocabulary. Where

are those terms found? In the use cases. Thus, they are a rich source to mine via noun phrase

identification.

Some of these noun phrases are candidate conceptual classes, some may refer to conceptual

classes that are ignored in this iteration (for example, "Accounting" and "commissions"), and

some may be attributes of conceptual classes.

A weakness of this approach is the imprecision of natural language; different noun phrases

may represent the same conceptual class or attribute, among other ambiguities. Nevertheless,

it is recommended in combination with the Conceptual Class Category List technique.

Specification or Description Conceptual Classes

The following discussion may at first seem related to a rare, highly specialized issue.

However, it turns out that the need for specification conceptual classes (as will be defined) is

common in any domain models. Thus, it is emphasized.

Note that in earlier times a register was just one possible implementation of how to record

sales. The term has acquired a generalized meaning over time.

Assume the following:

1. An Item instance represents a physical item in a store; as such, it may even have a serial

number.

2. An Item has a description, price, and itemID, which are not recorded anywhere else.

3. Everyone working in the store has amnesia.

4. Every time a real physical item is sold, a corresponding software instance of Item is deleted

from "software land."

With these assumptions, what happens in the following scenario?

There is strong demand for the popular new vegetarian burger—ObjectBurger. The store sells

out, implying that all Item instances of ObjectBurgers are deleted from computer memory.

Now, here is the heart of the problem: If someone asks, "How much do Object Burgers cost?",

no one can answer, because the memory of their price was attached to inventoried instances,

which were deleted as they were sold.



Notice also that the current model, if implemented in software as described, has duplicate data

and is space-inefficient because the description, price, and itemID are duplicated for every

Item instance of the same product.

The Need for Specification or Description Conceptual Classes

The preceding problem illustrates the need for a concept of objects that are specifications or

descriptions of other things. To solve the Item problem, what is needed is a

ProductSpecification (or ItemSpecification, ProductDescription, ...) conceptual class that

records information about items. A ProductSpecification does not represent an Item, it

represents a description of information about items. Note that even if all inventoried items are

sold and their corresponding Item software instances are deleted, the ProductSpecifications

still remain.

Description or specification objects are strongly related to the things they describe. In a

domain model, it is common to state that an XSpecification Describes an X.

The need for specification conceptual classes is common in sales and product domains. It is

also common in manufacturing, where a description of a manufactured thing is required that is

distinct from the thing itself. Time and space have been taken in motivating specification

conceptual classes because they are very common; it is not a rare modeling concept.

When Are Specification Conceptual Classes Required?

The following guideline suggests when to use specifications:

Add a specification or description conceptual class (for example, ProductSpecification) when:

1. There needs to be a description about an item or service, independent of the current existence

of any examples of those items or services.

2. Deleting instances of things they describe (for example, Item) results in a loss of information

that needs to be maintained, due to the incorrect association of information with the deleted

thing.

3. It reduces redundant or duplicated information.

2.6 Association, Aggregation and Composition Relationships

2.6.1 Association

It is a simple structural connection or channel between classes and is a relationship where all

objects have their own lifecycle and there is no owner. Lets take an example of Department

and Student. Multiple students can associate with a single Department and single student can



associate with multiple Departments, but there is no ownership between the objects and both

have their own lifecycle. Both can create and delete independently. Here is respective Model

and Code for the above example.

Aggregation

It is a specialize form of Association where all object have their own lifecycle but there is a

ownership like parent and child. Child object can not belong to another parent object at the

same time. We can think of it as "has-a" relationship. Implementation details: 1. Typically we

use pointer variables that point to an object that lives outside the scope of the aggregate class

2. Can use reference values that point to an object that lives outside the scope of the aggregate

class 3. Not responsible for creating/destroying subclasses Lets take an example of Employee

and Company. A single Employee can not belong to multiple Companies (legally!! ), but if we

delete the Company, Employee object will not destroy. Here is respective Model and Code for

the above example.



Composition

It is again specialize form of Aggregation. It is a strong type of Aggregation. Here the Parent

and Child objects have coincident lifetimes. Child object dose not have it's own lifecycle and

if parent object gets deleted, then all of it's child objects will also be deleted.

Implementation details:

1. Typically we use normal member variables

2. Can use pointer values if the composition class automatically handles allocation/deallocation

3. Responsible for creation/destruction of subclasses

Lets take an example of a relationship between House and it's Rooms. House can contain

multiple rooms there is no independent life for room and any room can not belong to two

different house. If we delete the house room will also be automatically deleted. Here is

respective Model and Code for the above example.



UML Activity Diagram

Overview:

Activity diagram is another important diagram in UML to describe dynamic aspects of the

system.

Activity diagram is basically a flow chart to represent the flow form one activity to another

activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential,

branched or concurrent. Activity diagrams deals with all type of flow control by using

different elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the

dynamic behaviour of the system. Other four diagrams are used to show the message flow

from one object to another but activity diagram is used to show message flow from one

activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for

visualizing dynamic nature of a system but they are also used to construct the executable

system by using forward and reverse engineering techniques. The only missing thing in

activity diagram is the message part.

It does not show any message flow from one activity to another. Activity diagram is some

time considered as the flow chart. Although the diagrams looks like a flow chart but it is not.

It shows different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Component Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the

system. But activity diagram are not exactly a flow chart as they have some additional

capabilities. These additional capabilities include branching, parallel flow, swimlane etc.



Before drawing an activity diagram we must have a clear understanding about the elements

used in activity diagram. The main element of an activity diagram is the activity itself. An

activity is a function performed by the system. After identifying the activities we need to

understand how they are associated with constraints and conditions.

So before drawing an activity diagram we should identify the following elements:

Activities

Association

Conditions

Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the entire

flow. This mental layout is then transformed into an activity diagram.

The following is an example of an activity diagram for order management system. In the diagram

four activities are identified which are associated with conditions. One important point should be

clearly understood that an activity diagram cannot be exactly matched with the code. The activity

diagram is made to understand the flow of activities and mainly used by the business users.

The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it is normal or special

order. After the type of order is identified dispatch activity is performed and that is marked as the

termination of the process.



Where to use Interaction Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage

is to model the control flow from one activity to another. This control flow does not include

messages.

The activity diagram is suitable for modeling the activity flow of the system. An application

can have multiple systems. Activity diagram also captures these systems and describes flow

from one system to another. This specific usage is not available in other diagrams. These

systems can be database, external queues or any other system.

Now we will look into the practical applications of the activity diagram. From the above

discussion it is clear that an activity diagram is drawn from a very high level. So it gives high

level view of a system. This high level view is mainly for business users or any other person

who is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. So

the diagram has more impact on business understanding rather implementation details.

Following are the main usages of activity diagram:

Modeling work flow by using activities.

Modeling business requirements.

High level understanding of the system's functionalities.



Investigate business requirements at a later stage.

Sequence Diagram

UML sequence diagrams are used to represent or model the flow of messages, events and actions

between the objects or components of a system. Time is represented in the vertical direction

showing the sequence of interactions of the header elements, which are displayed horizontally at

the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the architecture,

interfaces and logic of the system by describing the sequence of actions that need to be performed

to complete a task or scenario.

UML sequence diagrams

in sequence diagrams and when they are used. These are the diagram elements that are supported

by the Sequence Diagram Editor tool. Some are not part of the UML are useful design tools

because they provide a dynamic view of the system behavior which can be difficult to extract

from static diagrams or specifications. Although UML sequence diagrams are typically used to

describe object-oriented software systems, they are also extremely useful as system engineering

tools to design system architectures, in business process engineering as process flow diagrams, as

message sequence charts and call flows for telecom/wireless system design, and for protocol stack

design and analysis.

Sequence Diagram Drawing Elements

It describes the basic drawing elements used specification and may not be supported by other

UML tools.

Sequence Diagram Header Elements

The header portion of the sequence diagram represents the components or objects of the system

being modeled and are laid out horizontally at the top of the diagram.

Actor

Represents an external person or entity that interacts with the system

Object



What can be modeled using sequence diagrams?

Sequence diagrams are particularly useful for modeling:

Complex interactions between components. Sequence diagrams are often used to design the

interactions between components of a system that need to work together to accomplish a task.

They are particularly useful when the components are being developed in parallel by different

teams (typical in wireless and telephony systems) because they support the design of robust

interfaces that cover multiple scenarios and special cases.

Use case elaboration. Usage scenarios describe a way the system may be used by its actors. The

UML sequence diagram can be used to flesh out the details of one or more use cases by

illustrating visually how the system will behave in a particular scenario. The use cases along

with their corresponding sequence diagrams describe the expected behavior of the system and

form a strong foundation for the development of system architectures with robust interfaces.

Distributed & web-based systems. When a system consists of distributed components (such as a

client communicating with one or more servers over the Internet), sequence diagrams can be

used to document and validate the architecture, interfaces and logic of each of these components

for a set of usage scenarios.

Complex logic. UML sequence diagrams are often used to model the logic of a complex feature by

showing the interactions between the various objects that collaborate to implement each

scenario. Modeling multiple scenarios showing different aspects of the feature helps developers

take into account special cases during implementation.

State machines. Telecom, wireless and embedded systems make extensive use of state machine

based designs where one or more state machines communicate with each other and with

external entities to perform their work. For example, each task in the protocol stack of a cellular

phone goes through a series of states to perform actions such as setup a call or register with a

new base station. Similarly the call processing components of a Mobile Switching Center use

state machines to control the registration and transfer of calls to roaming subscribers. Sequence

diagrams (or call flows as they are commonly referred to in the telecom and wireless industry)

are useful for these types of applications because they can visually depict the messages being

exchanged between the components and their associated state transitions.

Benefits of using UML sequence diagrams

These are some of the main benefits of using UML sequence diagrams.



1. Help you discover architectural, interface and logic problems early. Because they allow you

to flesh out details before having to implement anything, sequence diagrams are useful tools to

find architectural, interface and logic problems early on in the design process. You can validate

your architecture, interfaces, state machine and logic by seeing how the system architecture

would handle different basic scenarios and special cases.

This is particularly true for systems involving the interaction of components that are being

implemented in parallel by different teams. In the cell phone example, each task would typically

be implemented by a separate team. Having a set of sequence diagrams describing how the

interfaces are actually used and what messages/actions are expected at different times gives

each team a consistent and robust implementation plan. You can also document how special

cases should be handled across the entire system. The very act of creating the sequence

diagrams and making them work with your architecture is valuable because it forces you to

think about details such as interfaces, states, message order, assignment of responsibilities,

timers/timeouts and special/error cases ahead of time.

2. Collaboration tool. Sequence diagrams are valuable collaboration tools during design meetings

because they allow you to discuss the design in concrete terms. You can see the interactions

between entities, various proposed state transitions and alternate courses/special cases on paper

as you discuss the design. In our experience, having a concrete design proposal during design

meetings greatly enhances the productivity of these meetings even if the proposed design has

problems. You can narrow down the problems and then make corrections to solve them. The

proposal serves as a concrete starting point for the discussion and as a place to capture proposed

changes. Sequence diagram editor makes it so easy to edit your sequence diagrams that you

could even make the corrections in real time during the meeting and instantly see the result of

the changes as you make them.

3. Documentation. Sequence diagrams can be used to document the dynamic view of the system

design at various levels of abstraction, which is often difficult to extract from static diagrams or

even the complete source code. The diagrams can abstract much of the implementation detail

and provide a high level view of system behavior. Below is a sequence diagram for making a

hotel reservation. The object initiating the sequence of messages is a Reservation window.



The Reservation window sends a makeReservation() message to a HotelChain. The

HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available

rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow

is a message call. An arrow goes from the sender to the top of the activation bar of the

message on the receiver's lifeline. The activation bar represents the duration of execution of

the message.

In our diagram, the Hotel issues a self call to determine if a room is available. If so, then

the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means

iteration (to make sure there is available room for each day of the stay in the hotel). The

expression in square brackets, [ ], is a condition.



UNIT-IV

4.1.The Architecture Concepts:

It provide a methodological analysis of design methods, by trying to analyze their forms

and to classify them in some way.)The idea of a method as a structured and ‗procedural‘ way of

doing things is on that should be familiar enough. ‗Methods‘ are used to structure the way that we

perform many routine tasks, such as making a cup of tea: Boil the kettle; warm the pot; add the tea;

pour on water; wait a number of minutes; pour the tea into the cup. Like most methods, this puts a

strong emphasis on the ordering of actions (if you don‘t think so, try changing the order of any of

the operations in the above example, and see what results!). However, it provides little or no

guidance on those issues that are more

a matter of taste, such as:

how much tea to add

how long to wait for the tea to brew

since these are personal preferences of the tea-maker. Since they are also essential to

the success of the tea-making process, we can reasonably conclude that ‗procedural‘ guidance

alone is insufficient for this purpose, and that some ‗domain knowledge‘ is also required. We can

devise methods for organizing many other activities, from driving a car to constructing kitchen

units, model aircraft and so on. However, such methods are rarely creative in quite the same sense

that we consider the act of design to be creative. Rather, these methods are recipes for doing

something that we have learned to do through ‗experiment‘ or ‗theory‘ (or some combination of

both). We might be able to adapt a method like that in the example above for other tasks (for

making coffee instead of tea, perhaps), but we cannot easily change its basic domain (that of

making hot drinks).

A design method is generally much less prescriptive than the kind of method that

we might use for making tea, or for assembling a new garden shed. Indeed, in some ways a

software design method can almost be considered as a ‗meta-method‘, in that it is used to

develop new processes, which in turn are ways of doing things – where the‗ doing‘ that is

involved will be the task of the computer. Returning to the tea-making example the analogy



in this case would be using a design method to design the form of the tea-making process

itself. So we can reasonably expect that a design method should identify a general strategy

to be used by the designer, and provide some rather general guidelines on its use, based

upon experience. However, a method cannot be expected to be very prescriptive about how

the ultimate solution to a problem is to be attained, since the specific design decisions

required will be determined by the nature of the problem, rather than by the method. (Think

of all the different processes that are used for making coffee!)

Vessey and Conger (1994) have suggested that the knowledge involved in successfully

employing a design method can be categorized into two forms:

1. declarative knowledge, describing what tasks need to be performed at each step in

the design process; and the rationale for method

2. procedural knowledge, consisting of knowledge about how to employ a given

method in a particular situation. In terms of our example of making tea, the declarative

knowledge would include the tasks to be performed, and the order in which they should be

performed (boiling water, adding tea to pot, adding water to pot), while the procedural

knowledge would address such issues as how much tea to add and how much water to use

when making tea for four people. Declarative knowledge is therefore fairly readily conveyed

through the use of a ‗do this, then do that‘ form of description, whereas procedural knowledge

is more likely to be acquired through experience. This experience may itself be acquired

directly (as is likely when the knowledge is about how to make tea) or through exposure to

case studies (which is probably more practical when the knowledge is about how to design

software). Since we often express the declarative knowledge in what we term a procedural

form, by specifying a sequence of actions that should be performed, this terminology can be a

little confusing, although both uses of ‗procedural‘ are quite reasonable ones! (It is also worth

noting that Détienne (2002) uses the terms declarative and procedural in yet another, slightly

different, way.)



Returning to the need to find ways of designing software: in Chapter 2, the following three main

components of a software design method were identified, and their relationships are shown in 8.1

The representation part consists of one or more forms of notation that can be used

to describe (or model) both the structure of the initial problem and that of the

intended solution, using one or more viewpoints and differing levels of abstraction.

What is a software design method?

The process part describes the procedures to follow in developing the solution and the

strategies to adopt in making choices. This generally involves the designer in making a series of

transformations on the different forms that comprise the representation part.

A set of heuristics or clichés provide guidelines on the ways in which the activities defined

in the process part can be organized for specific classes of problem. These are generally based on

experience of past use of the method with a particular problem domain, or for a particular form of

structure. In terms of the classification of knowledge discussed above, the process part can be

considered as embodying the declarative knowledge, while heuristics are more concerned with

procedural knowledge. This description will be elaborated further in the next chapter; for the moment

these terms will provide a very general descriptive framework. Software design methods fall into two

very broad and general categories. These are essentially distinguished by the forms of representation



that are used, although in turn the representation forms have some influence upon the forms of

process that can be used within them

Formal methods largely depend on the use of mathematical notations for the representation

parts. These notations permit a degree of consistency checking between the descriptions used in the

different stages of design, as well as more rigorous design transformations. However, while the

representation parts for such methods have been the subject of considerable research and

development, the process parts are less well refined and are apt to be developments of the ‗top-down‘

strategy which is discussed more fully in Section 9.3.

This imbalance leads us to ask whether the term ‗Formal Method‘ is really the most

appropriate description. Because of this, the term Formal Description Technique (FDT) is sometimes

preferred, as one that emphasizes the powerful notational aspects while playing down the much

weaker procedural element. Figure 8.2 Some properties of formal and systematic software design

methods. The rationale for method Systematic methods are generally less mathematically rigorous in

form, both in terms of the representation part – which normally consists of one or more forms of

diagram – and also of the process part. This is true even for those methods that are

Generally considered to be more prescriptive in their form, such as JSP and SSADM. As a

consequence, there is far more scope to use ‗mix and match‘ techniques with systematic methods, in

which ideas or representation forms from one method can be used to help resolve a particular issue,

even though the design is being developed using the strategy of another method.



The third component of a design method, the heuristics (or clichés) usually consist of a set

of techniques that are recommended for use in handling particular situations that may be encountered

across a wide variety of problems. These heuristics are generally built up over a period of time, as

experience is gained with using the method in a wider problem domain, and so they are essentially

experiential in origin, although they may be highly systematic in form. We will encounter a number

of examples of these in later chapters, and they play an important role in allowing a designer to reuse

the experience of others. Examples of heuristics can be found in both systematic and formal methods.

The design methods discussed in this book are all systematic in their form, although we will also

examine an example of an FDT in Chapter 18. This bias partly reflects the relative preponderance of

systematic methods in current industrial practices, and partly the wider variety of design models that

they tend to provide.

The rest of this chapter will examine in greater detail the rationale for using any method to

design software, and will consider some of the limitations that generally apply to the use of a design

method.8.2 The support that design methods provide Since this is a book about design and design

methods, it is not unreasonable at this point to raise the question: why should anyone use a method at

all? Indeed, probably considerably more software has so far been produced without the use of an

explicit design method than through the use of such methods – so what benefits might be expected

from making use of a software design method (whatever form this might take)? Some answers to this

were identified and were summarized at the beginning of this chapter. The last of these, that of

providing an artificial framework to assist with thinking about an intrinsically invisible set of

elements, is an important one, and one that is largely addressed by the representation parts of design

methods. A second reason, and one that draws upon both the representation and process parts, is

simply that of scale. Software-based systems increasingly underpin almost all aspects of a modern

society. Some, such as those used to handle financial transactions within banks and similar

institutions, were designed with the expectation that they would be large systems, while others may

have become large through an undirected

Process of aggregation. (An example of the latter is the growth of many websites, where

different elements are owned and maintained by separate individuals or organizations, but the site

may still form a virtual whole.) For the former in particular, the cognitive tasks involved in planning

and understanding such degrees of complexity are The support that design methods provide ones that

may be usefully supported by using a systematic and structured approach to development and



maintenance. For the latter, the need to ensure consistent behavior and the need to facilitate

integration between diverse elements also imply the need for some degree of standardization, at least

to the level of being able to describe the structures involved. While such systems are less obviously

candidates for the use of design methods, there is certainly scope to employ the representation

elements and possibly some of the more strategic ideas. One of the implicit features of design

methods is that the use of any method will lead to designs that employ the architectural style

associated with that method. With the long service life of much software, one way of preserving the

integrity and structure of a system is to develop and maintain it by using a single design method.

There are therefore two aspects of the software development process (and of the subsequent

maintenance task that normally goes with software systems) that can be expected to benefit from

using a method to provide a structured and systematic approach to the development process. These

are:

technical issues

management issues

and so both of these are considered in this section. Technical issues‘ consist of the problem-related

aspects of design. There are a number of these to consider, with the relative importance of each one

being somewhat dependent upon a range of external factors such as the structure of the development

organization, as well as the nature of the design problem itself. So the following points should not be

considered as ranked in any particular order.

The use of a design method should help the designer to produce a system that is structured

in a consistent way, which may be particularly important if the design is being produced by a team of

designers who will need to ensure that their contributions fit together correctly. In such a case, the use

of a design method both helps with defining the chosen architectural form and also establishes a set of

common standards, criteria and goals for use by the team.

The use of a method should lead to the production of records and representations in standard form

that can be used by a maintenance team to capture and understand the intentions of the original

designer(s) This allows the system maintainers to make changes consistent with the overall

structuring of The rationale for method the system, as originally planned, and so to help preserve its

integrity.



4.2.Design Methods:

Design methods is a broad area that focuses on:

Divergence – Exploring possibilities and constraints of inherited situations by applying critical

thinking through qualitative and quantitative research methods to create new understanding

(problem space) toward better design solutions

Transformation – Redefining specifications of design solutions which can lead to better

guidelines for traditional and contemporary design activities (architecture, graphic, industrial,

information, interaction, et al.) and/or multidisciplinary response

Convergence – Prototyping possible scenarios for better design solutions that incrementally or

significantly improve the originally inherited situation

Sustainability – Managing the process of exploring, redefining and prototyping of design

solutions continually over time

Articulation - the visual relationship between the parts and the whole.

The role of design methods is to support design work, the aims of which can be varied, though

they may include gaining key insights or unique essential truths resulting in more holistic

solutions in order to achieve better experiences for users with products, services, environments

and systems they rely upon. Insight, in this case, is clear and deep investigation of a situation

through design methods, thereby grasping the inner nature of things intuitively.

Expansion of design methods

Different groups took John Chris Jones's book Design Methods, with its alternative message of

using design as a framework for exploration and improvement, in different directions.

Emergence of design research and design studies

In the late 1950s and early 1960s, graduates of the Ulm School of Design in Germany

(Hochschule für Gestaltung - HfG Ulm: 1953–1968).[1][2]

began to spread Horst Rittel's approach

of design methodology across Europe and the United States in context of their professional work

and teaching what became known as the 'Ulm Model'.[2]

Likewise, after the 1962 conference in England, many of the participants began to publish and to

define an area of research that focused on design. Three "camps" seemed to emerge to integrate

the initial work in Design Methods:

http://en.wikipedia.org/wiki/Divergence

http://en.wikipedia.org/wiki/Critical_thinking



http://en.wiktionary.org/wiki/Convergence

http://en.wikipedia.org/wiki/Prototyping

http://en.wikipedia.org/wiki/Sustainability

http://en.wikipedia.org/wiki/Articulation_%28architecture%29

http://en.wikipedia.org/wiki/Holistic

http://en.wikipedia.org/wiki/Conceptual_framework

http://en.wikipedia.org/wiki/Exploration

http://en.wikipedia.org/wiki/Ulm_School_of_Design

http://en.wikipedia.org/wiki/Design_methods#cite_note-Ulm1-1






Behaviorism interpreted Design Methods as a way to describe human behavior in relation

to the built environment. Its clinical approach tended to rely on human behavior processes

(taxonomic activities).

Reductivism broke Design Methods down into small constituent parts. This scientific

approach tended to rely on rationalism and objectified processes such as epistemological

activities.

Phenomenology approached design methods from an experiential approach (human

experience and perception.)

The following is what design research is concerned with:

The physical embodiment of man-made things, how these things perform their jobs, and

how their users perceive and employ them

Construction as a human activity, how designers work, how they think, and how they carry

out design activity, and how non-designers participate in the process

What is achieved at the end of a purposeful design activity, how an artificial thing appears,

and what it means

Embodiment of configurations

Systematic search and acquisition of knowledge related to design and design activity

4.3.Design Processes and Design Strategies

The role of strategy in Design by top-down methods decomposition, Describing the design

Design by composition process – the D-Matrix , Organizational influences upon design Each design

method embodies a design strategy within its process part, which gives a sense of direction to the

procedures of the method and forms one of the elements that make up its basic philosophy about

designing. Following a discussion about the roles of strategy in design, this chapter introduces some

simple process modelling forms which can be used to help with describing the design processes

themselves. It then goes on to examine some of the more widely adopted strategies, together with

the principles that underpin these. Strategies are not necessarily wholly based upon technical

factors, and so we also examine how they can be influenced by the needs of organizational users of

software.

http://en.wikipedia.org/wiki/Human_behavior

http://en.wikipedia.org/wiki/Taxonomic

http://en.wikipedia.org/wiki/Epistemological

http://en.wikipedia.org/wiki/Perception

http://en.wikipedia.org/wiki/Design_research



principal components:

representation part

process part

set of heuristics, or clichés

The properties of some widely used forms of representation have already been described here.it

was further observed that the set of these used in a method are important in defining the Design

Virtual Machine (DVM) that is embodied in a method, since they determine the type and form of

design model(s) that a designer is encouraged to produce when using the method. The process part of

a method is closely entwined with the representation part, since it provides ‗procedural‘ guidelines on

how the models should be developed. We have General procedural model of the software design

process.The role of strategy in methods

now look more closely at the nature and form of the process part, while in later chapters the

three components are brought together when we look at examples of design methods and examine the

specific forms of heuristic that are associated with them.It shows this procedural model of the

software design process in a symbolic fashion, and we will be making use of this form throughout the

rest of this book. The basic symbols it uses to describe a design method are:

an oblong to denote a representation form;

an oval to denote a procedural step;



an arc to denote the sequence of steps.

These can be seen more fully here which shows a slightly expanded form (Note that our

notation possesses the important property of being hierarchical, as discussed later, in that the

description of any transformation step can be expanded further using the same three components.)

The iterations that Expanded view of the procedural model of the software design process

.Design processes and design strategies occur between phases of the design process are not shown

explicitly: the model is concerned with describing overall strategy rather than the detailed sequencing

of actions, since these will be driven by the needs of a specific problem and the experience of the

designer in a brief and introductory discussion about the form of the typical process part of design

methods, we made the distinction between a ‗transformation‘ step and one concerned with

‗elaboration‘. Now that we need to consider design processes and strategies in rather more detail, it is

useful to examine this categorization more closely. This is because each of the procedural steps of any

design method, regardless of the strategy employed, can usually be classified as being one of those

two forms. These two forms have quite distinctive roles and characteristics, which can be described as

below.

A transformation step is one where the designer modifies the structuring for their model of

the ‗system‘ in some way. Typically this consists of reinterpreting it using a different viewpoint

(ultimately, of course, the aim is to produce a constructional model). Such a step will require the

designer to make some fairly major design decisions and is clearly a strongly creative one.

An elaboration step is one which does not usually involve any change of viewpoint,

but is more concerned with restructuring or reorganizing the design model within the current

viewpoint. (Examples might include expanding the bubbles in a DFD, or grouping states

within a State chart.) The purpose of an elaboration step is usually either to add further

information to the model, or to obtain greater insight into the current state of the design plan

through restructuring, and as such it may be an preliminary to a successful transformation

step. When we come to examine some examples of design methods, we will see that many of

these have only one transformation step, usually preceded and followed by elaboration steps.

Important factors from a methodological aspect are whether the transformation step appears

early or late in the sequence of steps, and the number (and types) of viewpoint that may be

involved. It is important to recognize that both types of step involve creative actions, although

the forms that the creativity takes are somewhat different. The transformation process



typically requires the designer to be able to bridge their ideas across two or more different sets

of properties, while the elaboration process is more concerned with recognizing patterns and

structures (or the potential for forming these), while also possibly anticipating the needs of

subsequent transformation.

We discuss later in this section are more likely to be embodied in the procedures employed

in the elaboration steps of a method. This general model, in which a sequence of procedural

steps make up the process part, is one that we will use extensively in analysing design

methods, and the notations shown in Figures 9.1 will be used for this. In the next section we

will introduce

a slightly more ‗formal‘ notation that complements this, and which places more emphasis

upon the use of the viewpoints model, so making a more explicit distinction between

transformation and elaboration steps.

Steps modify artifacts. In ‗derivation‘, a new artifact is created. In ‗revision‘, a new

version of an existing artifact is created.

Steps raise issues. This may occur automatically, but the issue may not have to be

addressed immediately.

Issues review artifacts. An issue may be raised to review the property of an artifact.

Positions respond to issues.

Arguments support positions.

Arguments object to positions. Arguments are often paired, with one supporting a

position and the other opposed to it.

Arguments cite artifacts. The artifact provides evidence for the argument.

Positions contribute to steps. A step is performed because a set of commitments has

been made.

The form of module employed in a design model is clearly related to the ideas about

architectural style and the evolution of the two has largely gone in parallel. Changes in the form of

module employed have reflected the evolution of ideas about how systems should be structured, and

how those structures might be achieved. Early thinking about design was concerned with making

effective use of the subprogram‘s strengths, and so was focused on partitioning system functionality

into sub-tasks, we will use the following broad groupings in order to discuss how strategy is

incorporated into a design method:



decomposition methods, which generally take a ‗top-down‘ view of the design process,

developing the design model through a process of sub-division;

compositional methods, whereby the basic design model is built up from the identification of

‗entities‘ of some form;

organizational methods, for which the structure of the design process is strongly influenced

by the requirement that it should conform to non-technical requirements that are based on the

form of the organization;

template-based methods, where a specific problem domain provides a class of problems that

can be tackled using a fairly standard strategy. The rest of this chapter examines the

characteristics of each of these strategies (with the exception of the last, which is addressed in

the next chapter), and makes an initial classification of methods in terms of them.

Design processes and design strategies Before proceeding, however, one other point should be

mentioned here: the relationship between strategy and such ancillary aspects as the design of the

user interface and the design of error-handling strategies. Design strategies (and associated

methods) tend to encourage the designer to focus on structuring core activities of the eventual

system in building up a model of a problem. As a result, such issues as the organization of

human–computer interactions (HCI) and the handling of error (exception) conditions are

generally deferred until a later stage in the design process, when the design model is being refined

and elaborated. This is generally a reasonable practice to adopt, particularly for such issues as

exception-handling, since any attempt to include these in the initial model may lead to it

becoming excessively complex. The designer is then faced with the following alternatives when

determining how to incorporate these issues:

To incorporate them into the later stages of design refinement, by which time architectural

decisions may have been made that are inconsistent with their needs;

To repeat the design process from a much earlier stage, using the experience gained from

producing a design for the basic problem to help with the greater complexity of the fuller

problem. As always with design, there is no hard and fast rule about which of these strategies

may be the most appropriate. Constraints such as project deadlines may push the designer

towards the former choice but, where significant HCI elements are involved, or where error-

handling is an important element, this may lead to considerable distortion of the design structure.



On the whole, existing design practices do not help greatly with either of these issues. HCI

design is now a rather specialized field in its own right, and designing for exceptions is a

relatively unexplored field in design theory. Before reviewing the major design strategies, we

now examine a ‗viewpoints centred‘ notation .

Describing the design process – the D-Matrix

4.4.Design Patterns

Design by template and

Designing with patterns

design reuse

Patterns in the wider design

The design pattern context Codifying design experience for reuse by others is not solely

embodied in procedural forms such as design methods, and the concept of a design pattern offers an

important alternative (and complementary) approach to recording design experience. In this chapter

we begin by examining the wider issues of reuse in software design and establish some criteria for a

‗template-based‘ approach to be practicable. We then examine the nature and form of design patterns

as used for Object-Oriented design,



identify some of the implications of their use in terms of design practice, and finally consider how

easily the concept can be expanded to use with other architectural styles, and what factors might aid

or limit this.

Design by template and design reuse we examined the principal ways in which a software

designer could reuse the experiences of other designers. While design methods have been a widely-

adopted and rather dominant mechanism for this, their general-purpose nature makes them unsuitable

for giving detailed guidance about the particular form of solution that might be adopted by a designer

when faced with a problem having specific characteristics. While the component of a method that we

have termed a heuristic (sometimes also referred to as a ‗cliché‘) does provide some scope to address

the question of how to approach certain well-defined classes of problem, the heuristics for most

methods are neither well codified nor even recorded and, even when they do exist, they are still An

alternative way to reuse experience of what has worked for others when faced with similar problems

is through the concept of some form of ‗design template‘.

Software design, were largely informal in nature. They were also relatively few in number,

since the basic requirements for developing and using a template are that the problem domain should:

be very well-identified, well-defined, and tightly constrained; and

contain a significant number of problems that each need a design solution; and further that

there should be some accepted form of constructional description that could be used for

describing the design template.

There are lots of streams needing to be crossed; and it is possible to describe the template by a

drawing. Indeed, one might argue that this last factor has been a, if not the, major problem in terms of

adapting this concept for use with software. The descriptive forms used with software that we

reviewed in

Organized more for describing the details of specific solutions than for portraying their general

forms, not least because any diagram still depends quite heavily upon the use of supplementary text.

At the level of detailed program design, the idea of ‗solution patterns‘, often referred to as idioms, is

fairly well-established (even if still not particularly well codified). At a very basic level of ‗coding-as-

design‘, the problem characteristics that determine which form of looping construct a programmer

should employ are familiar enough ‗templates‘ to most programmers.

Equally, more advanced and slightly more abstract level, the basic structure that needs to be

employed for interrupt-handling is a recognizable pattern which must then be adapted if it is to be



mapped on to both the specific features of a particular processor architecture and the particular device

characteristics.

At more abstract levels of design, the one good example of wide reuse of design experience is that

of compiler-writing. No-one would now begin to develop a new compiler from scratch by using a

general-purpose design method, since the basic rules for the organization of compilers are particularly

well understood. (The adoption of such a compiler-writing ‗pattern‘ is further encouraged by the

availability of tools perform such tasks as lexical analysis and parsing, which in turn exist because the

form of compilers is standard enough to merit putting effort into developing such reusable

components.)

4.5 Describing object-oriented design patterns

In architectural terms, the evolution of the ‗object concept‘ has been one of the major

developments of the 1980s and 1990s. While our main discussion of this will be provided here. we

have inevitably needed to consider some of its characteristics in earlier chapters, and in this chapter

we again adopt the view that only those characteristics of specific relevance to the use of design

patterns will be considered here. In brief, an ‗object‘ can be viewed as being an evolutionary

development of the concept of the abstract data type, that provides an abstraction of a part-solution

that:

possesses a state which is encapsulated within the object;

exhibits behaviour in that it responds to external events;

possesses an identity (there may be more than one object of a given type); where the

inspection/modification of its state can only be achieved through the use of those external

methods that are provided by the object as its interface to the outside world.

For the purposes of this chapter, the key features of an object are that it provides an abstraction of

the part-solution, that it incorporates the notion of encapsulation of state information, and that it

provides externally accessible methods. We should note one, some have argued that many ‗real-

world‘ problems can themselves be modeled in terms of ‗real-world‘ objects. Hence one approach

to object-oriented design is to identify these real-world objects and develop a solution by

providing corresponding implementation objects that model their behaviour. For most purposes,



however, the design patterns community has concentrated on describing implementational objects

provide reusable elements of solutions rather than on describing problem objects.

1. Their purpose. The purpose describes what a pattern is used for, and is usually

described as being one of the following three types:

creational patterns are concerned with object creation;

structural patterns address the way in which classes or objects are composed;

behavioral patterns describe the way that classes or objects interact, and how responsibility is

allocated between them.

2. Their scope. This describes whether the pattern is primarily one that addresses the use of classes or

the use of objects (where we can regard classes as being the ‗templates‘ from which objects are

instantiated). Most patterns deal with objects, and we will not attempt to discuss the use of class

patterns in this book. In contrast, Buschmann et al. (1996) use a framework that is much more

concerned with design hierarchy. Whereas the GoF focus upon design patterns Buschmann et al.

takes a wider view of pattern applicability, including for: n architectural style (architectural patterns

relating to the form of the overall system);

design (design patterns that relate to the detailed form of subsystems);

programming (idioms that describe the broad structure of code).

For the case of design patterns, they adopt a scheme of grouping patterns under the following set of

role-based headings.

Structural decomposition where patterns ‗support a suitable decomposition of subsystems and

complex components into cooperating parts‘, with the term ‗structural‘ being used in a similar

sense as by the GoF.

Organization of work which is concerned with component collaboration (a bit like the GoF‘s

concept of ‗behaviour‘).

Access control describes patterns that ‗guard and control access to services or components‘,

which we can again recognize as a form of structural grouping.

Management where patterns address the organization of collections of objects (roughly

structural again).

Communication which is concerned with (obviously) communication between system

components.



4.5 Stepwise Refinement

The historical role of stepwise:

Strengths and weaknesses of refinement the stepwise strategy Architectural consequences -

Historically, this can be regarded as the first form of ‗design method‘ to be used for software design

on any scale. Although much of its importance lies in its influence upon the form and strategy

employed in many later methods, its universality has also meant that it has been used widely for

software development, and so it does merit a short chapter in its own right. We review both its role

and form, and consider some of the consequences that arise from its use.

The historical role of stepwise refinement: Since the early days of computing, the designer

of software has been faced with the need to address complex problems using a medium that is

enormously powerful and flexible, and yet is also ill-defined in terms of the way in which its detailed

form is organized. As already observed, the subprogram (whether termed a subroutine, procedure,

function or method . . . ) has probably formed the most important mechanism for providing structural

organization in many programming languages.

In this approach, a top-down ‗process of successive refinement of specifications‘ led to ‗the

decomposition of tasks into sub-tasks and of data into data structures‘. The latter phrase is significant,

since Wirth sought to consider how both function and data could be structured within the same

process, although subsequent thinking would appear to have placed much more emphasis upon the

question of function. This may be partly because in his example solution to the classical eight-queens

problem,* the refinement of ideas about data representations was performed at a relatively late stage

in the process. Indeed, Wirth argued that, because it could be difficult to foresee the operations on the

data that might eventually be needed, it was ‗advisable to delay decisions

about data representation as long as possible‘.

4.6.Incremental Design

Black box to white box

Prototyping in stages

An example – DSDM



In a book such as this, where software design activities form the principal object of study, it is

easy to develop a rather compartmentalized view of design activities and of the context within which

they are performed.

This chapter considers how design activities are organized within a more dynamic context,

where they need to be interleaved with other developmental tasks, and where they may be constrained

by having only limited time available for completion. In such a context, the control of design

activities becomes of paramount importance. Indeed, when we examine an example of a design

method that supports this style of development, we find that its main elements are those concerned

with the organization of the processes involved. Incremental design

Black box to white box in stages:

In some ways, this chapter can be considered as representing something of an ‗aside‘ when

it is viewed from the context of the design practices that form the dominant theme of the preceding

and following chapters. Yet it deals with an important issue and, indeed, highlights some of the

underlying assumptions adopted in many of our approaches to the task of designing software. The

title of this section (which, as we will demonstrate, is probably not very accurate) emphasizes the key

tenet of incremental development through the term ‗in stages‘.

Implicit in almost all procedural approaches to software design is the idea that we begin

with some form of ‗requirements specification‘ that is agreed with the customer and which then forms

the basis for developing a black box model, and eventually from this a white box model that conforms

to that specification.

In practice, it is widely recognized that this is a rather unrealistic situation, although it is

one that is often necessitated by contractual or other factors. There are situations where a very

comprehensive and inclusive requirements specification can be provided at the start of development,

but these are relatively uncommon. In addition, over the period needed for the development of any

sizeable software system, the requirements may evolve or even change dramatically, for both

technical and organizational reasons. So, the development of any design solution is very likely to

involve some degree of interaction with the customer throughout the design process. The difference

this then highlights is between conventional procedural design approaches, which try to minimize the

perturbations that this creates for the design solution, and incremental approaches, which seek to

incorporate this interaction as a fully-fledged element of the design process and so control and



manage its effects. Incremental development is often termed Rapid Application Development, or

RAD, and the approaches used for RAD are sometimes termed Agile Methods, with the development

practices of Extreme Programming, or XP, representing the ‗outer limits‘ of such approaches

(Boehm, 2002). In terms of the philosophy that underpins Agile Methods, Boehm suggests that they

favour:

individuals and interactions over processes and tools;

working software over comprehensive documentation;

customer collaboration over contract negotiation;

responding to change over following a plan.

Of course, taken to the extreme, both Agile Methods and procedural development practices can be

abused and misused. The agile approach can degenerate into unstructured ‗hacking‘ of code,

while the procedural approach can become bureaucratic and document-bound. However, an

awareness of the strengths and limitations of both

forms should be a part of any software developer‘s knowledge-set, along with an appreciation of

how they are best (and least-suitably) deployed. In Chapter 3 we identified some reasons why an

incremental development process might be adopted, which included situations where:

there may be a need to demonstrate that an idea is feasible;

it may be necessary or even essential, for business purposes, to establish a market position as

rapidly as possible;

the ‗customer‘ may wish to establish whether a market exists for a product before committing

to large-scale investment.

Underlying all of these is the concept of risk, whether it be a risk that a given solution is not

feasible; one of missing out on a market opportunity; or that no real market may actually exist.

Risk is also an important element in Boehm‘s spiral model processes effectively assume a

lifecycle model of this form, rather than the more linear ‗waterfall‘ forms that tend to be implicitly

embodied in procedural design methods. The adoption of an incremental development process is

therefore likely to be favored in those situations where an organization needs to maintain its

position in volatile and rapidly-changing markets, and where minimizing time-to-market is a

particularly important constraint. (This applies whether the software is itself being marketed or

whether, as is more likely, it is being used to market an organization‘s services or products.) Such



organizations are sometimes characterized as being emergent in nature. An emergent

organization can be defined as one that is ‗in a state of continual

1. To develop the ‗black box‘ model for the system, in a situation where the purpose of the

eventual system may need to be explored with the customer. (This is less likely to be a situation

where the customer doesn‘t know what they want, than one where they don‘t know what is really

feasible, especially if there are severe time constraints on implementation.) Such a role

corresponds roughly to the idea of exploratory prototyping that was

‗enhancing the information that is provided from the requirements analysis and functional

specification activities‘, with the distinction that here we are to some extent undertaking the

second of these tasks.

2. To develop a working solution (white box) within a set of resource constraints. Time is

probably the most likely form of resource constraint although, where new developments are

concerned, an organization may be unwilling to invest heavily in terms of staff effort until

convinced of the likely benefits. Here, the key need may

well be to deliver a solution on time, even with some elements of functionality missing or

curtailed.

For the rest of this chapter we are largely concerned with the second of these roles for incremental

development, since this is more in keeping with our emphasis upon studying design activities. It is

also more in keeping with the notion of the emergent organization, where there is no real

likelihood or expectation of ever creating a ‗final‘ system, since such organizations are

characterized by a ‗continuous redevelopment perspective‘ incremental design approach is not

closely tied to any particular design strategy or architectural style. This is not to say that

architectural style is not important. Achieving the goal of ‗continuous change‘ requires an overall

framework which enables extensive use of ‗plug-and-play‘ extensions to a system. Indeed, an

important technical factor is to recognize that a system is being designed for change, and to

facilitate this as far as possible. Maintaining the ‗separation of concerns‘ needed for plug-and-play

is more a matter of attention to detailed design, rather than one that is affected by the choice of a

specific architectural style. Where the use of an incremental approach to design does affect the act



of designing is in the way that the design process needs to be organized in order to provide the

degree of control necessary to meet the constraints. when deciding whether to adopt such an

approach. Incremental design is an approach that is less commonly encountered in conventional

forms of engineering design. As a technique it is unlikely to find much favor with civil engineers

(‗after we have built the central span of the bridge, we‘ll work out how to construct the

approaches‘), any more than with their chemical or electrical counterparts. This is not to argue

that it is not a valid engineering approach, given adequate planning and control, but rather that it

is an approach which only makes sense when used with a medium such as software, and within

the type of dynamically changing context often met in software-based business use and in the

emergent organizations that such software makes possible.

One issue that can easily become blurred where incremental development is employed is the

distinction between design and implementation.

4.6.Prototyping

Incremental approach is likely to involve some interleaving of design stages with implementation.

However, the design stages are likely to be ‗detailed design‘ activities, occurring with a context

established by a set of overall architectural design decisions that are made before the incremental

phases begin.

Evolutionary. This is the form closest to our idea of ‗incremental development‘ of a system. The

software for a system is adapted gradually, by changing the requirements step by step as

these become clearer with use, and changing the system to fit them. In this form,

prototyping is used to develop a product and the prototype gradually evolves into the end

product.

Experimental. This role is distinguished by the use of the prototype for evaluating a possible

solution to a problem, by developing it in advance of large-scale implementation. The

reasons for doing this may be manifold, including the assessment of performance and

resource needs, evaluation of the effectiveness of a particular form of user interface,

assessment of an algorithm and so on. This form of prototype is essentially intended to be a



‗throw-away‘ item, and might well be implemented in a quite different form to that which

will be used for the final system itself.

4.7 Structured System Analysis and Structured Design

Exploratory. In this role a prototype is used to help with clarification of user requirements

and possibly with identifying how introducing the system might lead to the need to modify the

wider work practices of an organization. One purpose might be to help with developing an

analysis of users‘ needs by providing a set of Profile of an incremental design process.

Incremental design possible models for them to use and assess. Essentially this form of prototype

is also likely to be a ‗throw-away‘ item, and it can be considered as enhancing the information

provided from the requirements analysis and the functional specification activities. For the

purposes of this chapter, we can see that the two roles of prototyping that are most likely to be

extensively employed in incremental development forms are the evolutionary and the exploratory.

The evolutionary role fits with the notion of the emergent organization that was briefly

described in the preceding section. Indeed, in such a context there is really no notion of there

being an ‗end product‘, only the notion of the ‗current state‘ of a system. Each new state of the

system is then achieved by modifying a previous state (not necessarily the ‗current state‘), or even

by creating a completely new implementation. So in a context where the incremental design



process is continuous and on-going, the development of software may closely approximate to a

continuous process of evolutionary prototyping. One of the characteristics of incremental design

is that it usually involves some degree of interaction with the ‗customer‘ (or with ‗end-users‘, who

may or may not be the customer.) Here we can see a role for the exploratory prototype, which

may address anything from very specific aspects of some element of a system through to the

functionality or behaviour of the complete system. Of course a prototype need not actually be an

item of software, especially where such aspects as possible scenarios for the use of a system are

being considered

An example – DSDM

Person‘s implementation language is another person‘s prototyping tool, and so the list is

really an endless one. So having examined some of the reasons why an incremental design

approach may be the appropriate one to adopt, and then briefly considered some of the

mechanisms for organizing the feedback needed for incremental design, we now need to conside

how the process might be structured. In the next section we examine an example of one approach

to RAD, in the shape of the DSDM method. An example – DSDM

4.8 DSDM

In this section we examine an example of how a ‗design method‘ that is based around an

RAD strategy is structured. The method that we will examine is the Dynamic Systems Development

Method, generally known as DSDM. This originated in 1994, and is managed by the ‗not-for-profit‘

UK-based DSDM Consortium (the associated trademark has a reversed second ‗D‘ character), which

is mainly made up of representatives

from the business community. At the time of writing, following a typical process of evolution, the

‗current‘ version of the DSDM method is DSDM is quite unlike any of the other design methods that

we examine in this book. It is almost entirely concerned with managing and controlling the RAD

process, and makes no assumptions about design strategy, notations or any of the other classical

‗method features‘. This is not to say that these issues are ignored in the DSDM design process, simply

that DSDM makes no assumptions about their particular form. Indeed, throughout the DSDM

lifecycle, there are two distinctive elements that emerge

very strongly:



The roles, responsibilities and activities that people undertake and perform;

The effect of business needs upon design decisions. As much as such things can be placed

in neat compartments, these factors mean that DSDM as a method can be considered as belonging in

what we sometimes term the Information Systems category. This is not to say that it would never be

used by (say) software engineers but, in terms of emphasis, it is far more concerned with business

issues than with technological ones. In the rest of this section we seek to examine DSDM from two

aspects. The first of these concerns the set of principles that underpin DSDM, since these principles

provide the rationale for its particular structure and practices.

The second aspect that we examine is the DSDM development cycle, which is where these

principles are interpreted to create its particular approach to systems development. We should also

note that the DSDM practices are concerned with the complete development life-cycle, from

establishing requirements through to planning maintenance although, as usual in this book, we will

chiefly concern ourselves with those elements that are concerned with the roles generally described

under the headings of ‗analysis and design‘.

The DSDM principles

DSDM is based around nine principles, which are invoked as necessary in order to decide on the

way that the development process should be structured. In brief, these are as follows.

1. Active user involvement is imperative. As mentioned above, DSDM has a very strong ‗people‘

element and users are seen as being active participants in the development process. Two examples of

very specific user roles encouraged in DSDM are the ambassador, who ‗guides the developers in their

activities to ensure that the solution being developed will accurately meet the needs of the business‘;

and the advisor, who is tasked with representing a particular user view (which might stem from

marketing issues, the IT operational support, etc.).

2. DSDM teams must be empowered to make decisions. This can be seen as being partially a

corollary of the previous principle. For active user involvement to work effectively, it is essential to

avoid the need for frequent consultation with higher-level management.

3. The focus is on frequent delivery of products. The DSDM process is based upon favouring a

product-focused view over an activity-focused one. There is also an emphasis upon allocating short

periods of time for performing various activities. (We should also note that the resulting products can

be interim design documents,



as well as prototypes or executable code.)

4. Fitness for business purpose is the essential criterion for acceptance of deliverables. DSDM

places the main emphasis upon ‗delivering the necessary functionality at the required time‘. In that

sense, it again takes a very different approach to those employed in the methods discussed in the

following chapters, where issues of structure are also considered as important criteria. The DSDM

view is that, once the functionality has been established, the solution can be re-engineered as

necessary.

5. Iterative and incremental development is necessary to converge on an accurate business

solution. While iteration is a normal element in any development process, it is not always easy to

incorporate this into an organization‘s procurement procedures. DSDM, however, explicitly makes

this an expectation, with the aim of

achieving continuous improvement in the system through its use.

6. All changes during development are reversible. Basically this means that configuration control

is an essential and all-pervasive element of the DSDM development context. As and when

necessary, it should always be possible to backtrack to reuse an earlier version as the basis for the

next incremental step in development.

7. Requirements are baseline at a high level. In contrast to ‗traditional‘ approaches, where the

documentation of system requirements may occupy several volumes of very detailed specification,

the DSDM approach is to freeze the requirements at a high level, but allow more detailed aspects

to evolve as necessary.

8. Testing is integrated throughout the lifecycle. Rather than being a separate ‗end of project‘

activity (as implied in the waterfall model) user acceptance testing of only partially-complete

software proceeds throughout the development process.

9. A collaborative and co-operative approach between all stakeholders is essential. The main

concern here is to involve stakeholders, implying that change control procedures should be kept as

‗light‘ as possible, so that short-term redirection of a project can be achieved through a shared

understanding, rather than as the outcome

of an adversarial conflict between developers and users. Enumerating these principles does

reinforce the earlier point that the focus of attention in DSDM is really upon business aims and

people. Before going on to see how the principles are embodied in the process, we need to examine



two other aspects of the ‗DSDM philosophy‘, both of which form important concepts for the

method.\

4.6 JSP-JSD

JSP is one of the two design methods described in this book that have emerged from ideas and

experiences of Michael Jackson (the second is JSD, Chapter 15). It has been chosen as the second

detailed example of a software design method for the following reasons. It has limited and define

applications, which make it possible to describe it more concisely yet fully than most other design

methods. Ever since its development in the early 1970s it has been widely used, and therefore has a

historical claim to be discussed in depth.

It is an excellent example of the use of a compositional design strategy.

It is well documented and widely used. However, some of the attributes that make JSP so valuable

for developing ideas about design also have the potential to mislead. Because of its limited domain

of application,

JSP provides more prescriptive forms of design transformation than almost any other

systematic design method, and this makes it possible to incorporate a greater degree of verification

than is generally practicable with other methods. JSP is essentially a program design method. It is

concerned with the design of systems that are realizable as a single sequential process; have well-

defined input and output data streams. JSP is therefore particularly well-suited to developing

systems that employ a pipe and- filter architectural style. Despite this, while historically it has

often been viewed as primarily of interest to the data-processing community, its use is by no means

restricted to such problems, as will be illustrated here by examples and in the discussion in the

final section. Indeed, because it is a program design method, there is scope to employ it in larger

system design practices: one such example is SSADM

JSP representation forms Since the forms of representation that are used in JSP have

already been described in considerable detail the discussion of this section will be kept to a

minimum.JSP is unusual as a design method, in that it uses only a single diagrammatical form in

its transformations. where its use for describing the sequences involved in both static data

structures and dynamic program behavior was demonstrated. It is used in JSP for modeling both

the structures of the data objects of interest, and the functional structuring of the program( s) that



manipulate them. as examples of Structure Diagrams being used in both these roles; the rules for

drawing them are shown in the box below.

Jackson Structured Programming (JSP)

Because JSP is concerned with program design, it places a strong emphasis on the

development of algorithms, and the detailed forms for these are usually better described through

the use of text. So JSP also makes use of pseudo code forms for the later stages of design, with

these being derived from the diagrammatical forms as a part of the design transformation process.

Some rules for drawing Structure Diagrams

sequence is represented by unmarked boxes

selection is represented by boxes marked with circles

iteration is represented by an asterisked box

sequencing is from left to right

the three forms may not be mixed in a sequence

the last selection part should always be condition less (the ELSE clause).



UNIT-V

CASE STUDIES

1)Domain name systems

2)Electronic Mail(EMAIL)

3)World Wide Web(WWW)

4)Protocol-HTTP

5)Protocol-SMTP

6)Protocol-FTP

7)Security

8)Multimedia applications

IT2053 Software Design A Course Material on · IT2053 Software Design SCE Department of Information...

Documents

Transcript of IT2053 Software Design A Course Material on · IT2053 Software Design SCE Department of Information...