Practical 10

11

Click here to load reader

Transcript of Practical 10

Page 1: Practical 10

5511203

PRACTICAL -10

Aim: To study software design. Explain it’s fundamental and design methods.

What is design?

Design is highly significant phase in the software development where the designer plans how a

software system should be produced in order to make it functional, reliable, reasonably easy to

understand, modify and maintain. A software requirements specifications document tells us what

a system does, and becomes input to the design process, which tells us how a software system

works. Designing software system means determining how requirements are realized and results

is a software design document (SDD). Thus, the purpose of design phase is to produce a solution

to a problem given in SRS document.

Conceptual and technical design

A process of software design involves the transformation of ideas into detailed implementation

descriptions, with the goal of satisfying the software requirements. To transform requirements

into a working system, designer must satisfy both customers and the system builders. The

customers understand what the system is to do. At the same time the system builders must

understand how the system is to work. So it is a iterative process that has two parts. First, we

produce conceptual design that tells the customer exactly what the system will do. Once the

customer approves the conceptual design, we translate the conceptual design into a much more

detailed document, the technical design, that allows system builders to understand the actual

hardware and software needed to solve the customer’s problem.

Objectives of design

The specification or the outside view of the program is used as a input for the inside view. So the

designs fill up the gap between specifications and decide how the program will be organized and

method it will use. The design needs to be

Correct and complete.

Understandable.

Page 2: Practical 10

5511203

At the right level.

Maintainable, and to facilitate maintenance of the produced codes.

Why design is important?

A good design is the key to successful product. The following are the attributes of a good design.

Durability.

Utility.

Charm.

A well defined system is easy to implement, understandable, and reliable and allows for smooth

evolution. Without design, we risk building an unstable system:

One that will fail when small changes are made.

One that will be difficult to maintain.

One whose quality cannot be assessed until late in the software process.

Design methods

There are two types of design methods:

Functional oriented

Object oriented

Functional oriented

The design process of a software system has the different levels. At the first level we decide

which modules are needed for the system. Then the specification of these modules and how the

modules are interconnected. The function oriented design approach is used to design where the

design is divided into set of interacting units where each unit has a well defined function. So the

system can be designed by a functional point of view. This function oriented approach is not

work better for the small programs. It is difficult in the large programs to implement it.

Design notations

For a function oriented design, the design can be represented graphically or mathematically by

the following:

Data flow diagram

Data dictionaries

Page 3: Practical 10

5511203

Structure charts

Pseudo codes

DATA FLOW DIAGRAM

It is known as a graphical technique that describes the information flow and the transmission that

are applied on data and move from input to output, it is also known as bubble chart.

Rules for constructing DFD

1. All the names should be unique.

2. DFD is not a flow chart because the arrows represent the flow of data.

3. It does not show the order of events.

4. The decision boxes are not present in the DFD.

Leveling of the DFD

DFD may be used to represent the system or software at any level of abstraction. It may be

divided into levels that represent increasing information flow at functional detail.

Level 0- in level 0 DFD known as fundamental system or context diagram. This model

represents the entire software as a single bubble with input and output represented by the

arrows then the other levels are made to solve the problem with multiple bubbles.

Level 1- to develop level 1 DFD examines the high level functional requirement. If there

are 3 to 7 functional requirments, they can be directly represented by bubble in the level 1

DFD. If a system has more then seven higher requirements then we combine them in a

level 1 DFD and split them into lower levels.

DATA DICTIONARIES

DD’S are used to store the information about the entire data item defined in DFD. It is an

organized list of the all data items. It is similar to the other dictionaries that contain the definition

of all the data elements.

Information stored in DD

Name of data item.

Other name of data item/ second name of data item.

Page 4: Practical 10

5511203

Description/ purpose of bubble.

Related data item.

Range of values.

Data structure definitions.

Structure charts

Structure chart is most commonly used method for design approach. It is divided into different

block boxes. A black box means the functionality is known to user without the knowledge of

internal details. The input is given to the black box and appropriate output will be generated. In a

structure chart a module is represented by rectangle box. The top level modules can call the

lower level modules for their functionality. The connections between these modules in structure

chart are represented by the solid lines. To make it easy to understand the modules should be

numbered. They can communicate by passing the control or data messages. Different notations

used in the structure charts are:

Pseudo codes

The pseudo code notation can be used for both preliminary design and detail design. Like flow

chart the pseudo code can be used at any desired level of abstraction it uses the structures to

define the logic without any limitation about the syntax. It just describes the flow of control. It

uses the keywords such as if, then, else, end, begin, and so on. They are language independent.

Object oriented design

Fig 10.1 An object

Page 5: Practical 10

5511203

Object oriented design is part of OO methodology and it forces programmers to think in terms

of objects, rather than procedures, when they plan their code. An object contains encapsulated

data and procedures grouped together to represent an entity. The 'object interface', how the object

can be interacted, is also defined. An object oriented program is described by the interaction of

these objects. Object Oriented Design is the discipline of defining the objects and their

interactions to solve a business problem that was identified and documented during object

oriented analysis.

The origin of object oriented programming is structured programming. Structured programming

fell short in big and complex programs. Object oriented methodology tries to remedy those

shortfalls.

The first object oriented languages were Simula and SmallTalk. The use of object oriented

languages became popular after Grady Booch wrote the first paper titled Object-Oriented

Design, in 1982.

Object oriented design is defined as a programming language that has five conceptual tools to aid

the programmer. These programs are often more readable than non-object oriented programs,

and debugging becomes easier with locality.

Input (sources) for object oriented design

Conceptual model (must have): Conceptual model is the result of object-oriented analysis; it

captures concepts in the problem domain. The conceptual model is explicitly chosen to be

independent of implementation details, such as concurrency or data storage.

Use case (must have): Use case is description of sequences of events that, taken together, lead to

a system doing something useful. Each use case provides one or more scenarios that convey how

the system should interact with the users called actors to achieve a specific business goal or

function. Use case actors may be end users or other systems.

System Sequence Diagram (should have): System Sequence diagram (SSD) is a picture that

shows, for a particular scenario of a use case, the events that external actors generate their order,

and possible inter-system events.

User interface documentations (if applicable): Document that shows and describes the look and

feel of the end product's user interface. This is not mandatory to have, but helps to visualize the

end-product and such helps the designer.

Page 6: Practical 10

5511203

Relational data model (if applicable): A data model is an abstract model that describes how data

is represented and used. If not object database is used, usually the relational data model should

be created before the design can start. How the relational to object mapping is done is included to

the OO design.

Object oriented concepts supported by an OO language

The five basic concepts of object oriented design are the implementation level features that are

built into the programming language. These features are often referred to by these common

names:

Encapsulation: A tight coupling or association of data structures with the methods or functions

that act on the data. This is called a class, or object (an object is often the implementation of a

class).

Information hiding: The ability to protect some components of the object from external entities.

This is realized by language keywords to enable a variable to be declared as private or protected

to the owning class.

Inheritance: The ability for a class to extend or override functionality of another class. The so

called child class has a whole section that is the parent class and then it has its own set of

functions and data.

Interface: A definition of functions or methods, and their signatures that are available for use to

manipulate a given instance of an object.

Polymorphism: The ability to define different functions or classes as having the same name but

taking different data types.

Designing concepts

Defining objects, creating class diagram from conceptual diagram: Usually map entity to class.

Identifying attributes.

Use design patterns (if applicable): A design pattern is not a finished design; it is a description of

a solution to a common problem. A design pattern can be reused in multiply application, and that

is the main advantage of using it. It can also be see as a template for how to solve a problem that

can be used in many different situations and/or applications. It is not code reuse, but code can be

Page 7: Practical 10

5511203

easily created from a design pattern. Object-oriented design patterns typically show relationships

and interactions between classes or objects, without specifying the final application classes or

objects that are involved.

Define application framework (if applicable): Application framework is a term usually used to

refer to a set of libraries or classes that are used to implement the standard structure of an

application for a specific operating system. By bundling a large amount of reusable code into a

framework, much time is saved for the developer, since he/she is saved the task of rewriting

large amounts of standard code for each new application that is developed.

Identify persisted objects/data (if applicable): Identify objects that have to be persisted. If

relational database is used design the object relation mapping.

Identify, define remote objects (if applicable)