Practical 10
Click here to load reader
-
Upload
abhilash-abhi -
Category
Documents
-
view
212 -
download
0
Transcript of 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.
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
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.
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
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.
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
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)