4.

DESIGN
Design is the first step in the development phase for any engineered product or system. It can be
defined as the process of applying various techniques and principles for the purpose of defining a
device or a system in sufficient detail to permit its physical realization.
Technical Criteria for Design:

o A design should exhibit a hierarchical organization that makes intelligent use of control
among elements of software.

o A design should be modular; that is, the software should be logically partitioned into
elements that perform specific functions and sub functions.

o A design should contain both data and procedural abstractions.

o A design should contain both data and procedural abstractions.
o A design should lead to modules that exhibit independent functional characteristics.
o A design should lead to interface that reduce the complexity of connections between
modules and with the external environment.

o A design should be derived using a repeatable method that is driven by information obtained
during the software requirements analysis.
Design Principles:
Software design is both a process and a model. The design process is a set of iterative steps
that enable the designer to describe all aspects of the software to be built.
Basic design principles enable the software engineer to navigate the design process
Some of the design principles are:

The design should be traceable.

The design should not reinvent the wheel.

The design should minimize intellectual distance between and the problem
as it exists in the real world.

The design should exhibit uniformity and integrity.

System Design is the transformation of the analysis model into a system design model. During
system design, developers define the design goals of the project
and decompose the system into smaller subsystem that can be realized by individual teams.

System Design includes:

The definition of design goals.

The decomposition of the system into subsystem.

The selection of off-the-shelf and legacy components.

The mapping of subsystem to hardware.

The selection of a persistent data management infrastructure.

The selection of an access control policy.

The selection of a global control.

15

The handling of boundary conditions.

DESIGN GOALS:
The design goals are derived from the non-functional requirements. Design goals guide the
decisions to be made by the developers especially when trade-offs are needed. It identifies the qualities
that our system should focus on.
The design goals are selected based on
o

Performance criteria.

Dependability criteria.

Cost Criteria.

Maintenance Criteria.

End user Criteria.

IDENTIFYING SUBSYSTEMS:
Finding the subsystems during system design has many similarities to finding objects during
analysis: It is a volatile activity driven by heuristics. Subsystem decomposition is constantly revised
whenever new issues are addressed: Subsystems are merged into one subsystem, a complex subsystem
is split into parts, and some subsystems are added to take care of new functionality.

The initial subsystem decomposition should be derived from the functional requirements. The
following are the subsystems found in the system.

System

Input Text File

Encrypting

Encrypted Bmp Files

Figure: Stegnography system as a set of three subsystems.

CURRENT SOFTWARE ARCHITECTURE

Software Architecture includes the system decomposition, the global control flow, errorhandling policies and inter-subsystem communication protocols.
The different architectures for the different systems are:

Repository Architecture.

Model/ View/ Controller (MVC).

Client/ Server Architecture.

16

Peer-To-Peer Architecture.

Pipe and Filter Architecture.

In the Repository Architecture, subsystems access and modify data from a single data structure called
central Repository. Subsystems are relatively independent, and interact only through the central data
structure. Control flow can be dictated either by the central repository or by the subsystems.
In the Model/ View/ Controller (MVC) Architecture, subsystems are classified into three different
types: model subsystems are responsible for maintaining domain knowledge, view subsystems are
responsible for displaying it into the user, and Controller subsystems are responsible for managing the
sequence of interactions with the user.
In the Client/ Server Architecture, a subsystem, the Server, provides services to instances of other
subsystems called the Clients, which are responsible for interacting with the user. In this, the request
for a service is usually done via a remote procedure call mechanism or a common object broker.
In the Peer-To-Peer Architecture, we consider it as a generalization of Client/ Server Architecture in
which, subsystems cannot act both as client and as servers, in the sense that each subsystem can request
and provide services. The control flow within each subsystem is independent from the others except for
synchronizations on requests.
In the Pipe and Filter Architecture, subsystems process data received from a set of inputs and send
results to other subsystems via a set of outputs. The subsystems are called Filters, and the associations
between the subsystems are called Pipes. Each filter only knows the content and format of the data
received on the input pipes, not the filters that produced them. Each filter is executed concurrently and
synchronization is done via the pipes. The Pipe and filter architecture is modifiable: Filters can be
substituted for others or reconfigured to achieve a different purpose.
The Software Architecture of the proposed system can be decided from the above theory is Repository.

Repository
Subsystem

getfile ()
getencrypt ()

Figure: Repository Software Architecture for the proposed system.

Here, the subsystems like Encryption/Decryption and others get the data from the central repository.
Then they process on that data independently.

HARDWARE/ SOFTWARE MAPPING

Selecting a hardware configuration also includes a virtual machine onto which the system
should be built. The virtual system includes the operating system and any software components that are
needed, such as database management system or a communication package. The selection of a virtual
machine reduces the distance between the system and the hardware platform on which it will run. The
more functionality, the components provide the less work involved.

17

For our proposed system we use JAVA as our development resource. To use this we need
MS DOS platform..
We also need the bmp image file for which the system has to provide security by using our proposed
system
Coming to the hardware mappings, we need at least 64MB of RAM and less than 1MB of Hard disk
space.

OBJECT DESIGN:

Introduction
During analysis, we saw the purpose of the system. This resulted in the identification of application
objects that represents user concepts. During system design, we saw the system in terms of its
architecture, such as its subsystem decomposition, its global control flow, and its persistency
management. There we also saw the Hardware, software platforms on which we build the system. Now
we turn on to object design.
Object Design Includes

Service specification, during which we precisely describe each class interface.

Component Selection, during which we identify additional off-the-shelf components and

solution objects.

Object model restructuring, during which we transform the object design model to improve its
understandability and extensibility.

Object model optimization, during which we transform the object design model to address
performance criteria such as response time or memory utilization.

During Object design we refine the analysis and system design models, identify new objects, and
close the gap between the application objects and off-the-shelf components.

Scenarios:
A Scenario is a narrative description of what people do and experience as they try to
make use of computer system and applications. A Scenario is concrete, focused, informal description
of a single feature of the system from the view point of a single actor.
Scenarios can have many different uses during requirement elicitation and during other
activities of the life cycle. The different types of scenarios are:
1.

As-is scenarios: These describe the current situation.

2.

Visionary scenarios: These describe a future system.

3.

Evaluation scenarios: These describe user talks against which the system is to be
evaluated.

18

4.

Training scenarios: These are tutorials used for introducing new users to the system.

Here are the different scenarios identified for the proposed system.

Scenario Name :

select a text file

Participating Actors :

Initiated by the user, communicates with

Steganography System.

Flow of Events :

1. The user upon initiating, the system asks the

user to enter the input parameter as a text file
that has to be sending.
2. The text file is converted into bmp file.

19

Scenario Name :

Convert into bmp image file.

Participating Actors :

Initiated by the user, communicates with

Steganography System.

Flow of Events :

1. The user enters 16-bit secret key.

2. The data in the text file is retired.
3. The user selects the encryption algorithm
in order to encrypt the data present in bmp
file.

20

Scenario Name :

decrypt the file

Participating Actors :

Initiated by the user, communicates with

Steganography System.

Flow of Events :

1. Select the encrypted bmp file

2.Provide 16-bit secret key again for
decrypting.
.

Scenario Name :

Get the Decrypted file

Participating Actors :

Initiated by the user

Flow of Events :

1. The encrypted bmp file from the list.

2. Then it is decrypted by using decryption
algorithm.
3.The decrypted file is converted into text
file

21

Use Case Model:

Use Case Diagrams, used during elicitation and analysis to represent the functionality of the
system. Use cases focus on the behavior of the system from an external point of view.
A use case describes a function provided by the system that yields a visible result for an actor.
Actors are external entities that interact with the system. Examples of actors include a user
role (e.g., a system administrator, a bank customer) or another system. Actors have unique names and
descriptions. Use cases describe the behavior of the system as seen from an actors point of view.
Behavior described by the use case model is also called external behavior. When actors and use cases
exchange information, they are said to communicate.
To describe a use case, we use a template composed of six fields:

The name of the use case is unique across the system so that developers can
unambiguously refer to the use case.

Participating actors are actors interacting with the use case.

Entry conditions describe the conditions that need to be satisfied before the use case
is initiated.

The flow of events describes the sequence of actions of the use case, which are
numbered for references. The common use cases and the exception cases are
described separately in different use cases for clarity.

Exit conditions describe the conditions that are satisfied after the completion of the
use case.

Special requirements are the requirements that are not related to the functionality of
the system. These include constraints on the performance of the system, its
implementation, the hardware platforms it runs on, and so on.

Use cases are written in natural language. This enables developers to use them for
communicating with the client and the users, who generally do not have an extensive knowledge of
software engineering notations.

Use Cases:
Use cases are a technique for capturing the functional requirements of a system. Use cases
work by describing the typical interactions between the users of a system and the system itself,
providing a narrative of how a system is used. Rather than describe use cases head-on, I find it easier to
sneak up on them from behind and start by describing scenarios. A scenario is a sequence of steps
describing an interaction between a user and a system.
A scenario is an instance of a use case, that is, a use case specifies all possible scenarios for a
given piece of functionality. An actor initiates a use case. After its initiation, a use case may interact
with other actors as well. A use case represents complete flow of events through the system in the sense
that it describes a series of related interactions that result from the initiation of the use case. The use of
scenarios and use cases to define the functionality of the system aims at creating requirements that are
validated by the user early in the development. As the design and implementation of the system starts,
the cost of changing the system specification and adding new unforeseen functionality increases.

22

Although the requirements change until late in the development, developers and users should strive to
address most requirement issues early. The focus of this activity is on completeness and correctness.
We should identify the functionality not covered in the scenarios and document it with new use cases.
We can have the following use cases for the Cluster analysis system as follows.
This scenario is one thing that can happen. However, the credit card authorization might fail, and this
would be a separate scenario. In another case, you may have a regular customer for whom you don't
need to capture the shipping and credit card information, and this is a third scenario. All these scenarios
are different yet similar. The essence of their similarity is that in all these three scenarios, the user has
the same goal: to buy a product. The user doesn't always succeed, but the goal remains. This user goal
is the key to use cases: A use case is a set of scenarios tied together by a common user goal. In use
casespeak, the users

23

Steganography

Choose File

Encrypt

Key request
Sender

bmp file

Key request
Reciever
Decrypt

Original Text
Figure: UML Use case for the Proposed System.

24

Use case Name :

Convert text into image file

Participating Actors :

Initiated by the user, communicates with

Steganography System.

Entry Condition:

User selects the TEXT file.

Flow of Events :

1. The user upon initiating, the system asks the

user to enter the input parameter as a text file
that has to be sending.
2.Providing 16-bit secret key.
3. The text file is converting into image file.

Exit Condition:

Text file is converted into Bmp image file.

25

Use case Name :

Encrypt text

Participating Actors :

Initiated by the user, communicates with

Steganography.

Entry Condition:

Selects the encryption algorithm and enters

key.

Flow of Events :

1. The file is checked weather it is text file or

not.
2. The data in the text file is retrieved.
3. The user selects the encryption algorithm
in order to encrypt the data present in image
file.
4. User encrypts the data by using the key
given.

Exit Condition:

The encrypted file (image file) is obtained.

26

Use case Name :

Participating Actors :

Decrypt file
Initiated by the user, communicates with
Steganography System.

Entry Condition:
Flow of Events :

Encrypted file is taken as input.

1. The encoded file is select.
2.Again provide the 16-bit secret key.
4.The image file convert into as text file.

Exit Condition:

Encrypted text file is Obtained.

27

Object Model:
Class Diagrams:
Class diagrams are used to describe the structure of the system. Classes are abstractions that
specify the common structure and behavior of a set of objects. Objects are instances of classes that are
created, modified, and destroyed during the execution of the system.
Properties represent structural features of a class. As a first approximation, you can think of properties
as corresponding to fields in a class. The reality is rather involved, as we shall see, but that's a
reasonable place to start. Properties are a single concept, but they appear in two quite distinct notations:
attributes and associations. Although they look quite different on a diagram, they are really the same
thing.

An association is a solid line between two classes, directed from the source class to the target class.
The name of the property goes at the target end of the association, together with its multiplicity. The
target end of the association links to the class that is the type of the property. Although most of the
same information appears in both notations, some items are different. In particular, associations can
show multiplicities.

28

Encrypted Text

Secret Key

Tag, encrypted
data, encrypted

Tag, encrypted
data, attributes

1..*

Image file

Provide Key ()

Select Text ()

Encrypted Image
File

Get Image ()

1
*

Decrypted File

Secret Key

Select the imge file

Provide the 16 bit

Secret Key

Get Original Text

Getting the Original
Message
GetText()

Select Image ()
SubmitKey()

Figure: UML Class diagram for the System.

Dynamic Models:

The dynamic models are the models, which are used to show the changes made up on the
decision of the user when a particular thing happens.

User interface:
The user will be given the main form, which displays different algorithms to be implemented.
User selects any or these entire algorithms and supplies key to the algorithm
In order to encrypt the file. Upon computing the system should display the encrypted text file.
Identification Of Objects

Entity Objects:
Entity objects represent the persistent information tracked by the system. The entity objects
identified for the proposed system are:

29

User

Text file

Boundary Objects:
These represent the interactions between the actors and the system. The boundary objects
identified for the proposed system are:

Main form

Select file Form

Key form

30

Control Objects:
These represent the tasks that are performed by the user and supported by the system. The
control objects identified for the proposed system are:
Encryption algorithm
Decryption algorithm
Key
Activity Diagrams:
Activity diagram describes the workflow behavior of a system. Activity diagrams can show
activities that are conditional or parallel. The diagrams describe the state of activities by showing the
sequence of activities performed. Activity diagrams show the Flow of activities through the system.
Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel
activities.

Key

Source
file

Encrypted

Decrypted
Algorithm

Encrypted
Algorithm

Original Text
File
Image File

Relevant
Output

Figure: Activity diagram for the proposed system

In the proposed system, a text file is taken in the source end. Conversion is performed in order
to create a image file. From there two activates can be performed depending on the users selection. In
one phase, encryption goes with encrypting algorithm with the help of key. It will be converting into
image file. In the other phase decrypting the file followed by decryption algorithm with the same key
on the image file.

Sequence Diagrams:

31

Sequence diagrams ties use cases with Objects. It shows how the behavior of a use case (or
scenario) is distributed among its participating objects. The columns of a sequence diagram represent
the objects that participate in the use case. The leftmost column is the actor who initiates the use case.
Horizontal arrows across the columns
Represent messages, or stimuli, which are sent from one object to the other. Time proceeds vertically
from top to bottom. The receipt of a message triggers the activation of an operation. The activation is
represented by a rectangle from which other messages can originate. The length of the rectangle
represents the time the operation is active. An operation can be thought of as a service that the object
provides to other objects.
The second column of a sequence diagram represents the boundary object with which the
actor interacts to initiate the use case. The third column is a control object that manages the rest of the
use case. From then on, the control object creates other boundary objects and may interact with other
control objects as well.

form

Text
File

Image

Key

Encrypt
Image

Enter()
Select ()
Build()
EncryptedImg()

selects()

Figure: Sequence diagram for encryption in proposed system

The above sequence diagram shows that the user is the one who initiates the system. The user
inputs the data that is needed for encrypting the given text file in to image file

32

33