MU for DOS doc

8/14/2019 MU for DOS doc

1/53

MULTI-UTILITY

AN OVERVIEW OF A GRAPHICAL USER

INTERFACE

COLLEGE OF ENGINEERING, TRIVANDRUM 1


2/53

MULTI-UTILITY

AN OVERVIEW OF A GRAPHICAL USER INTERFACE

Graphical user interfaces, such as Microsoft Windows and the one used by the Apple

Macintosh, feature the following basic components:

Pointer: A symbol that appears on the display screen and that you move to select

objects and commands. Usually, the pointer appears as a small angled arrow. Text

-processing applications, however, use an I-beam pointer that is shaped like a

capital I.

Pointing device: A device, such as a mouse or trackball that enables you to select

objects on the display screen.

Icons: Small pictures that represent commands, files, or windows. By moving thepointer to the icon and pressing a mouse button, you can execute a command or

convert the icon into a window. You can also move the icons around the display

screen as if they were real objects on your desk.

Desktop: The area on the display screen where icons are grouped is often referred

to as the desktop because the icons are intended to represent real objects on a real

desktop.

Windows: You can divide the screen into different areas. In each window, you

can run a different program or display a different file. You can move windows

around the display screen, and change their shape and size at will.

Menus: Most graphical user interfaces let you execute commands by selecting a

choice from a menu.

Today's major operating systems provide a graphical user

interface. A GUI sometimes uses one or more metaphors for objects familiar in real life,

such as the desktop, the view through a window, or the physical layout in a building.. A

system's graphical user interface along with its input devices is sometimes referred to as

its "look-and-feel.".The user interfaces is the part of an interactive system, application, or

telematic service with which the user comes into contact cognitively, perceptually, and

physically.



3/53

MULTI-UTILITY

Characteristics of a good GUI

Future interfaces

In order to be able to design everyone interfaces, we need to develop

interface strategies and techniques that facilitate building interfaces that are: straight

forward and easy to learn, flexible and adaptable, and modality independent.

Straight forward and easy to learn:

Interfaces must be simple, straight forward, and easy to learn, so that as

much of the population as possible is able to use them, and so that all users can master

new functions and capabilities easily.

Flexible and adaptable:

We will need interfaces that take advantage of fine motor movement and

three-dimensional gestures when a users situation and abilities allow. At the same time,

the interfaces should be operable using speech, keyboard, or other input techniques as

necessitated by the users environment, activities, and motor or other constraints.

Modality independent:

The interfaces will need to allow the user to choose the presentation

modalities that are appropriate to their environment, situation, or individual

characteristics. Systems will need to let users obtain information visually at some times

and auditorially at others; on high-resolution displays when they are available, and on

smaller, low-resolution displays, when that is all that is at hand.

Enhanced interface architectures are needed to achieve everyone interfaces.

These new interfaces must support multiple modalities. In addition, users will need to

seamlessly, coherently, and intuitively switch between modalities. They will need to

switch between input and control techniques as well as display formats, all based on

compatibility with changing environments.



4/53

MULTI-UTILITY

OBJECT ORIENTED TECHNIQUES



5/53

MULTI-UTILITY

OBJECT ORIENTED TECHNIQUES

Object oriented programming methodology is used for the

implementation of our software "MULTI-UTILITY". Object oriented programming has

its own advantages such as modular programming ,structural programming ,proceduralprogramming etc.

In procedural programming it is difficult to identify the flow of

control.This type of flow of control creates problems if one has to identify errors in a

program.One has to go through the program entirely from the beginning .To eliminate

these problems the concepts of structured programming and modular programming has

evolved.

In modular programminga large program can be broken down into a

number of functions, each of which performs a specific welldefined task.The purpose of

breaking down a program into functions can be extended by grouping functions together

into a larger entity called a module .However the principle is similar :grouping of

elements into smaller units to carryout specific tasks.This programming paradigm,also

known as 'data hiding principle'states : 'Decide which module you want; partition the

program so that data is hidden in modules'.

Structured programmingis a style of programming in which the program

code is divided into logically structured chunks of code.An organized approach to

programming involve the use of three basic structures-sequence,branch and loop and also

the concept of top down approach to decompose main functions into low level

components for modular coding purposes.

In Object Oriented Programming we have a web of interacting

objects,each housing its own state figure.This is a methodology that allows the

assosiation of data structures with operations similar to the way it is perceived by thehuman mind. They associate specific set of actions with a given type of object and

actions are based on these assosiations.The object oriented programming has been

developed based on certain concepts like data abstraction, data encapsulation,

inheritance, polymorphism and data hiding., to overcome the drawback of conventional

programming approaches.



6/53

MULTI-UTILITY

GENERAL CONCEPTS OF OOP

In object-oriented programming, a class consists of encapsulated

instance variables and subprograms, the methods mentioned below. A Class describes the

rules by which objects behave; these objects are referred to as "instances" of that class. A

class specifies the structure of data which each instance contains as well as the methods

(functions) which manipulate the data of the object; such methods are sometimes

described as "behavior". A class is the most specific type of an object in relation to a

specific layer.

Classes are sometimes described as "blueprints"; instances of a class will

have certain aspects in common. One might describe a "class of animals" (dogs), or a

"class of tangible objects" (computers). One of the benefits of programming with classes

is that all instances of a particular class will follow the defined behaviour of said class.

For example: if humans are a class, then each person is an instance of an object of the

human class. Each person is generally alike; but varies in such properties as "height" and

"weight". The class would list such instance variables; and also define, via methods, the

actions which humans can perform: "run", "jump", "sleep", "throw object", etc.

An abstract class is one that is designed only as aparent class and from

which child classes may be derived, and which is not itself suitable for instantiation. The

incomplete features of the abstract class are then shared by a group of sibling sub-classes

which add different variations of the missing pieces. In C++, an abstract class is defined

as a class having at least one virtual function without an implementation.Abstract classes

are superclasses which contain abstract methods and are defined such that subclasses are

to extend them by implementing the methods. Before a class derived from an abstract

class can be instantiated, it must implement particular methods for all the abstract

methods of its parent classes.

A concrete class is a class for which entities (instances) may be created.

This contrasts with abstract classes which cannot be instantiated because it defeats its

purpose of being an 'abstract'.



7/53

MULTI-UTILITY

Classes are often related in some way. The most popular of these relations

is inheritance, which involves subclasses and superclasses, also known respectively as

child classes (orderived classes) andparent classes(orbase classes).

The wrapping up of data and functions that operate on that data into asingle unit called class is called as encapsulation.Object encapsulates data and its

associated funcions and complexities are hidden from the outside environment.This

principle is known as data hiding or data encapsulation .

Data Abstraction is the act of representing essential features without

including the backgrounddetails or explanations.It refers to the creation of new data types

using the encapsulated items that are well suited to an application to be programmed.The

advantage of this method is that it will lead to the creation of more flexible and readable

programs.

Inheritance allows the creation of new classes referred to as derived

classes from already existing classes (base classes),thus enabling the creation of hierarchy

of classes that simulate the class and subclass concept of real world. Object oriented

languages express their inheritance relationship by allowing one class to inherit from

another. Different types of Inheritance:

Single Inheritance : It represents a derived class with only one base class.

Multiple Inheritance : It represents a derived class with more than one base class

Hierarchial Inheritance : The traits of one class may be inherited by more than

one class. This process is known as hierarchial inheritance.

Multilevel Inheritance : The process mechanism of deriving a class from another

derived class is referred to as Multilevel Inheritance.

Hybrid Inheritance : It represents the combination of multiple, multilevel

inheritance.



8/53

MULTI-UTILITY

Polymorphism is the ability of data or message to be processed in more than

one form. It allows a single name/operator to be assosiated with different operations

depending on the type of data passed to it. This is acheived by function overloading,

operator overloading & dynamic overloading. It is the property by which same message

can be sent to objects of different classes and each object can respond in a different way

depending upon its class.It allows an entity to take variety of representations.

Persistence is the phenomenon where an object outlives a program execution

time and exists between executions of the program.The lifetime of an object can be

extended by copying it into a file for late reading. This characteristic is called Object

Persistence.. Persistence saves the state and class of an object across time or space.

Delegation is an alternative to class inheritance .It is a way of making

object composition as powerful as inheritance. In delegation two objects are involved in

handling a request: receiving object delegates operations to its delegate.

Genericity is a technique for defining software components that have

more than one interpretation depending upon the data type of parameters.It allows the

declaration of data items without specifying the actual data type .Such unknown data

types (Generic data types) are resolved at the time of their usage(function call) based on

data type of parameters.

There are several advantages for object oriented programming :

Data Abstraction and Data hiding increases the reliability.

Inheritance combined with dynamic binding enhances code reusability.

Dynamic binding increases flexibility

Software complexity can be easily managed.

It is easy to partition the work in a project based on objects.

The data-centered design approachenables us to capture more details of a model in

implementable form.

Object-oriented systems can be asily upgraded from small to large systems.



9/53

MULTI-UTILITY

WHY USING C++?

C++ is a super-set of C.The C++ language removes almost all of the

problems assosiated with c by offering improved compile-time, type checking and

support for object oriented programming.

The most important facilities that C++ adds on to C are

classes,inheritance,function overloading and operator overloading,constant types,inline

functions,references,virtual function stream for console and file manipulation,templates

and exception handling.These features enable the creating of abstract data types ,inherit

properties from existing datatypes and support polymorphism,thereby making C++ a

truly object-oriented language .

The goal of C++ is improved productivity .C++ is designed to be

practical;C++ language design decisions were based on providing the maximum benefits

to the programmer.

C++ has a feature called references that allows more convinient handling

of addresses for function arguements and return values. The handling of names is

improved through a feature like called function overloading,which allows you to use the

same name for different functions .A feature called namespaces also improves the control

of names.There are numerous control features that improve the safety of C.C++ is an

extention of C,not a complete new syntax and programming model.It allows us to

continue creating useful code,applying the features gradually as one learns and

understands them.This may be one of the reasons for the success of C++ .

A number of features in C++ are intended to allow you to tune for

performance when the generated code isn't efficient enough.The design produced for an

OOP program may actually be more efficient than the C counterpart .

Error handling in C is a notorious problem , and one that is often ignored

-finger - crossing is usually involved. if you are building a large, complex program ,there

is nothing worst than having an error buried somewhere with no clue as to where it came

from . C++ exceptional handling is a way to guarantee that an error is noticed and that

something happens as a result .



10/53

MULTI-UTILITY

WHY DID WE CHOOSE OOT?

Let us think about the scenario if we use the traditional procedure oriented

approach to this problem also. Using the procedure oriented approach a problem is

viewed as a sequence of things to do, which may be called as

functions,subroutines,subprograms or procedures. The implementation of this paradigm

may cause some disadvantages.

Second case is that the above mentioned paradigm may treat the main

data as global because of the priority conventions described above.If the project needs to

be modified by another programmer, he may cause some damage to the data which is

declared as global. This is easy to do because each and every function has complete

access to the data.

Third and final problem with this approach is that as the data is accessed

by many functions its storage becomes critical. The arrangement of data cannot be

changed without modifying the functions accessing it. In a large program like this

modifying all functions accessing the main data becomes a tedious work and is

theoretically impossible.

On the overall, procedural approach fails to give an optimum solution for

our problem. Thus we are left with the choice of Object Oriented Technique, which is a

recent development in the programming world. When we approach a problem with this

concept, we think how to divide the problem into objects rather than dividing it into

functions.Thinking in terms of objects is due to close resemblance of the programming

objects with the real world objects. The fundamental idea behind this technique is to

combine both data and functions that operate on them into a single unit,called an object.

The objects functions provide the only way to access the data. The data is thus hidden,

so it is safe from accidental alteration.

Since our project deals with various functions in a Piano, the primary

concern is how to prevent the data from accidental changes. This can be achieved best

with OOT which provides features that simplifies writing, debugging and maintaining

program.



11/53

MULTI-UTILITY

FEATURES IMPLEMENTED

Here we have implemented a software MULTI-UTILITY.

The functions of this are:

SCHEDULER

CLOCK

SCREEN SAVER

EXIT

CLOCK:Clock is used to display time.As this key is pressed this function

displays time.

SCHEDULER: It is used for scheduling purposes.

SCREEN SAVER: It is automatically inititaled if the system is ideal for some time.

EXIT: clicking on this icon we can quit from the software & coming back to real

operating system.


SCHEDULER SCREEN SAVER EXITCLOCK


12/53

MULTI-UTILITY

OBJECT ORIENTED ANALYSIS

The object- oriented paradigm is a new and different way of thinking

about programming and many folks have at first knowing how to approach a new project.

Once you know everything is supposed to be an object,and as you learn to think more in

an object-oriented style,you can begin to create "good" designs that take advantage of all

the benefits that OOP has to offer .

A method is a set of processes and heuristics used to break down the

complexity of a programming problem.Especially in OOP,methodology is a field of

many experiments ,so it is important to understand what problem the method is trying to

solve before you consider adopting one. This is particularly true with C++, in which the

programming language is intended to reduce the complexity(compared to C) involved in

expressing a program.Instead,simpler ones may suffice in C++ for a much larger class of

problems than you could handle using simple methodologies with procedural languages.

While you are going through the development process, the most

important issue is this: Don't get lost .Most of the analysis and design methods are

intended to solve the largest of problems. Remember that most projects do not fit into that

category , so you can usually have successful analysis and design with a relatively small

subset of a method recommends.

Its also easy to get stuck, to fall into " analysis paralysis", where you feel

like you cant move forward because you have not laid down every little detail at the

current stage. Remember no matter how much analysis you do ,there are somethings

about a system that won't reveal themselves until design time , and more things that won't

reveal themselves until your coding , or not even until a program is up and running .

This point is worth emphasizing. Because of the history we have had with

procedural languages,it is commentable that a team will want to proceed carefully and

understand every minute detail before moving to design and implementation . certainly ,

when creating a DBMS , it pays to understand customers needs thoroughly . But a

DBMS is in a class of problems that is very well- post and well - understood; in many

such programs , the data base structure is the problem to be tackled.



13/53

MULTI-UTILITY

Five stages of Object Design:

The design life of an object is not limited to the time when you are writing

the program.Instead, the design of an object appears over a sequence of stages .It is

helpful to have this perspective because you stop expecting perfection right away;insteadyou realize that understanding of what an object does and what it should look like

happens over time .

Object discovery:Objects may be discovered by looking for external factors and

boundaries,duplication of elements in the elements and the smallest conceptual

units.Some objects are obvious if you already have a set of class libraries.

Object Assembly: As you are building an object you discover the need for new

members that didn't appear during discovery .The internal needs of the objects

may require other classes to support it .

System Construction : The need for communication and interconnection with

other objects in the system may change the needs of your classes and require new

classes.

System Extention : As you add new features to your system,you can restructure

parts of a system ,possibly adding new classses or class hierarchies.

Object Reuse : If someone tries to reuse it in an entirely new situation ,they will

probably discover some shortcomings. As you change a class to adapt to more

new programs,the general principals of the class will become clearer,until you

have a truly reusable type.Reusable types tend to be less common,and they must

solve more general problem inorder to be reusable.

As the name indicates , the object -oriented paradigm places a greater emphasis on the

objects that encapsulates data and procedures.They play the central role in all the stages

of software development and therefore exist a high degree of overlap and iteration

between the stages .The entire development process becomes evolutionary in nature Any

graphical representation of the object -oriented version of the software development life

cycle must, therefore, take into account these two aspects of overlap and iteration .



14/53

MULTI-UTILITY

SYSTEM REQUIREMENTS



15/53

MULTI-UTILITY

SYSTEM REQUIREMENTS

Hardware/SoftwareRequirements

ProcessorIntel Pentium II 400 MHz

or higher

Motherboard Intel 440 BX or higher

RAM 64 MB or more

HDD 4.3 GB or more

FDD 1.44 MB

CD ROM 48x IDE

Monitor 14 SVGA Color or more

Keyboard 104 Key QWERTY PS/2

Mouse3 button Microsoft

standard mouse

Operating System Windows 98 or higher



16/53

MULTI-UTILITY

SOFTWARE DEVELOPMENT PROCESS



17/53

MULTI-UTILITY

SOFTWARE DEVELOPMENT PROCESS

Over the past decades software has become an important part of an increasing

number of technical systems in the fields of aeronautics,communication,electrical,etc.as

well as economic systems and services such as industrial production and trading

systems,stock exchanges,and banking corporations. The software development process

that consists of analysis, design, implementation, testingand refinement is to transform

users needs into a software solution that satisfies those needs.system development can be

treated as a process. The development itself is a process of change, refinement ,

transformation or addition to already existing product.The process can be divided into

small,interacting phases calledsub processes. The sub processes must be defined clearly.

Also each sub processe should be allowed to carry out its activity which is totally

independent of other sub processes in the system. Each sub process must have the

following.

Describing the sequence of works.

Input specifications required for the process.

Specification of output to be produced.

Production of High-Quality SoftwareThe high quality product must meet users needs and expectations. Also

the products should achieve this with no or minimum defects. The focus is on improving

products at the time of production itself prior to delivery rather than correcting them after

delivery. Both, reduced internal complexity of software systems through well-thought-

out structuring and better reusability,are viewed as key factors in improving software

quality from a technical point of view. These factors are very important and object

oriented concepts prove useful in defining a better internal software structure when

compared to that produced with convectional software development methods.

Software Quality Attributes.



18/53

MULTI-UTILITY

Correctness: A software product satisfies given needs.also it is free from errors.

Ease of use: The software product should be easy to learn and use.

Reusability: It represents the ability of whole software system or some parts of it

to be reused in other software processes.

Readability: The effort required in understanding a piece of software.

Efficiency: It represents the optimum use of available hardware and software

resources.

Portability: It is the ease with which software is transferred to other hardware

and/or software platforms.

Software quality depends on several factors. The criteria

relevant for the end user and the designer of the software may be totally different.hence

care should be taken to meet the demands and requirements of end user,who is the

cusumer and software designer has to adjust the design in accordance with the end users

requirement.

Measures for producing high quality software.

Blum describes a means of system evaluation in terms of four quality

measures as follows.

Correspondence: Measures how well the delivered system matches the needs of

the operational environment as described in the orginal requirement statement.

Validation: It is the task of predicting correspondence.

Correctness: Measures the consistency of the product requirements with respsct

to the design specification.

Verification: It is the exercise of determining correctness.Specification and a

product will be given ,it should be possible to determine if the product precisely

satisfies the requirements of the specification.



19/53

MULTI-UTILITY

UNIFIED MODELING LANGUAGE

UML is a non-proprietary, third generation modeling and specification

language. The UML is an open method used to specify, visualize, construct and

document the artifacts of an object-oriented software-intensive system under

development. The UML represents a compilation of "best engineering practices" which

have proven successful in modeling large, complex systems, especially at the

architectural level.

UML integrates the concepts of Booch, OMT, OOSE and Class-Relation

by fusing them into a single, common and widely usable modeling language. UML aims

to be a standard modeling language which can model concurrent and distributed systems.

UML is not an industry standard, but is taking shape under the auspices of

the Object Management Group (OMG). OMG has called for information on object-

oriented methodologies that might create a rigorous software modeling language. Many

industry leaders have responded in earnest to help create the standard.

There are three prominent models of the UML system development:

Functional Model: Showcases the functionality of the system from the User's

Point of View. Includes Use Cases Diagrams.

Object Model: Showcases the structure and substructure of the system using

objects, attributes, operations, and associations. Includes Class Diagrams

Dynamic Model: Showcases the internal behaviour of the system. Includes

Sequence Diagrams, Activity Diagrams, Statechart Diagrams.



20/53

MULTI-UTILITY

It is important to distinguish between a UML model, and a UML diagram,

or set of diagrams, including Use Case Diagram, Collaboration Diagram, Activity

Diagram, Sequence Diagram, Deployment Diagram, Component Diagram, Class

Diagram, State Chart Diagrama UML diagram is a graphical representation of the

information in the model, but the model exists independently. XMI in its current version

provides interchange for the model, but not for the diagrams.

Since UML is not a methodology, it does not require any formal work

products. Yet it does provide several types of diagrams that, when used within a given

methodology, increase the ease of understanding an application under development.

There is more to UML than these diagrams, but for my purposes here, the diagrams offer

a good introduction to the language and the principles behind its use. By placing standard

UML diagrams in your methodology's work products, you make it easier for UML-

proficient people to join your project and quickly become productive. The most useful,

standard UML diagrams are: use case diagram, class diagram, sequence diagram, state

chart diagram, activity diagram, component diagram, and deployment diagram.

UML USAGE

UML has been effectively used in domains such as :EIS(Enterprise

Information System) ,Banking and financial services, Telecommunications

,Transportation Defense/Aerospace,Retail,Retail,Medical Electronics,Scientific and

Distributed Web-based services.

It can be used with all processes throughout the development life cycle

,and across different implementation technologies.

Some of the known users of UML are Ericson,MCI systems ,Republic

Bank,Oracle HP,Microsoft etc.

UML ARCHITECTURE

Architecture is used to manage different view pionts and hence

control the iterative and incrementaldevelopment of systems throughout its life cycle

Each of the above five views can stand alone so that different stake holder can focus on

the issues of the systems architecture that most concern them .The 5 views interact with

each other .



21/53

MULTI-UTILITY

UML PRIMARY GOALS

The primary goals in the design of UML are :

1. Provide users a ready- to -use ,expressive visual modeling language so that they can

develop and exchange meaningful models .

2. Provide extensibility and specialization mechanisms to extend the core concepts .

3. Be independant of particular programming languages and development processes.

4. Provide the required formal basics for understanding the modeling language .

5. Encourage the use of OO tools market .

6. Support development concepts at higher level.

7. Intergrate best practices and methodologies.

UML FOUNDATIONS

The vocabulary of UML encompasses 3 kinds of building blocks :

THINGS

Things are abstractions ;Relationships tie things together ; Diagrams group

interesting collection if things .There are four kinds of things in UML . They

are structured things,behavioural things ,grouping things and annotational

things .

Structural things :They are nouns and static parts of model .The seven

structural things are class interferance collaboration ,use case,active

class,component,and node.

Behavioral things : They are verbs and dynamic parts of UML ,representing

behaviour over time and space.The 2 behavioural things are interaction and

Interaction and State Machine


THINGS, RELATIONSHIPS, DIAGRAMS


22/53

MULTI-UTILITY

Grouping things: They are the organizational parts of UML.A package is a

grouping thing where structural behaviouraland even other grouping things

are grouped in a package

Annotational things: They are explanatory parts of the models.These are thecomments applied to describe ,illuminate and remark about an element in the

model .A note is an example for it .

RELATIONSHIP

Relationshipis a sematic connection among elements .The different kinds

of relationship in UML are Dependancy , Assosiation ,Generalization and Realization

DIAGRAMS

Every complex system is best approched through a small set of nearly

independant views of a model; no single view is sufficient . The nine graphical diagrams

of UML are classified into static and dynamic diagrams .


STATIC/STRUCTURAL DIAGRAMS DYNAMIC/BEHAVIOUR DIAGRAMS

1. Class Diagrams 1. Use Case Diagram

2. Object Diagram 2. Interaction Diagram

3. Implementation Diagram 2.1 Sequence diagram

3.1 Component Diagram 2.2 Collaboration Diagram

3.2 Deployment Diagram 3. State Diagram

4. Activity Diagram


23/53

MULTI-UTILITY

THE UML DIAGRAMS

RULES OF UML

The UML has the following schematic rules. to become a well-

formed model .

Names What you call things ,relationships and diagrams.

Scope The context that gives specific meaning to names .

Visibility How those names can be seen and used by others .

Intergrity How things properly and consistently relate to one another.

Execution What it means to run or simulate a dynamic model.

Some times it is required to build models which are Elided

(certain elements are hidden) ,Incomplete (when elements are not identified )and

Inconsistent (missing intergrity in certain parts ) .These types of models are

unavoidable in certain specific cases.

PRIMARY MODEL ELEMENTS IN UML

Class: A template for a set of objects that share a common structure and a common

behaviour

Use case : A named behaviour involving the collaboration have a society of objects .

State : The condition of an object .

Interface :The public part of an object .



24/53

MULTI-UTILITY

Active Class : Capable of concurrent activity with all other active classes .

Component : A reusable element ,typically having both logical as well as physical

aspects .

Node : A hardware device upon which software may reside and /execute .

Package : A container of elements .

Note : A comment , explanation or annotation .



25/53

MULTI-UTILITY

COMMON MECHANISMS OF UML

The UML is made simpler by the presence of four common

mechanisms that apply consistently throughout the language .

1 Specifications

2 Adornments

3 Common divisions.

4 Extensibuility Mechanisms .

1.Specifications : Specifications provide a textual statament of the syntax and the

semantics of the building blocks .UML's graphical notation is used to visualize a system;

whereas UML's specification is used to state the system's details . The UML's

specification provide a sematic back plane that contains all the parts of all the models of

the system , each part related to one another in a consistent fashion . The UML's

diagrams are thus simply visual projections into that back plane , each diagram revealing

a specific interesting aspect of a system .

2.Adornments : Most elements in the UML has a unique and direct graphical notation

that provides a visual representation of the most important aspects of the elements .For

example , the notation of a class is intentionally designed to be easy to draw , and also

exposes the most important aspects of the class , namely its name attributes and

operation . Every element in the UML's notation starts with a basic symbol ,to whichcan

be added a variety of adornments specific to the symbol .

3.Common divisions : In modelling object-oriented system , the world often gets in

atleast a couple of ways .First there is the division of class and object. A class is an

abstraction ; an object is one concrete manifestation of that abstraction .Graphically , the

UML distinguishes an object by using the same symbol as its class and then simply

underlying the object name


Class :Object


26/53

MULTI-UTILITY

4.Extensibility Mechanisms : The UML provides a standard language for software

bluprints . The UML is a open -ended, making it possible to extent the language in

controlled ways to express all the nuances of all models across all domains aross all

time.

The UML's extensibility mechanisms include

sterotypes

Tagged values

Constraints

These extensibility mechanisms allow to shape and grow the UML to the project's needs.

USE-CASE DIAGRAM

A use case illustrates a unit of functionality provided by the system. The

main purpose of the use-case diagram is to help development teams visualize the

functional requirements of a system, including the relationship of "actors" (human beings

who will interact with the system) to essential processes, as well as the relationships

among different use cases. Use-case diagrams generally show groups of use cases

either all use cases for the complete system, or a breakout of a particular group of use

cases with related functionality (e.g., all security administration-related use cases). To

show a use case on a use-case diagram, you draw an oval in the middle of the diagram

and put the name of the use case in the center of, or below, the oval. To draw an actor

(indicating a system user) on a use-case diagram, you draw a stick person to the left or

right of your diagram (and just in case you're wondering, some people draw prettier stick

people than others). Use simple lines to depict relationships between actors and use cases,

as shown in Figure.



27/53

MULTI-UTILITY

A use-case diagram is typically used to communicate the high-level

functions of the system and the system's scope. The outcome of the business object

analysis - Business process layer is to identify classes and the relationships that play a

role in acheiving system goals.

Use Case is relatively large end to end process description that typically

includes many steps for transactions ; It is not normally an individual step or activity in a

process .Use cases are scenarios for understanding system requirements .

An actor is an user playing a role with respect to system .The actor is the

key to finding the correct use cases.The actor can be an external system that needs

information from the current system.

Use Case diagram is used to indicate the existence of the use cases, actors

and their relation ships and the courses of actions that can be performed .It is used to

illustrate the static use case view of a system The purpose of a diagram is to p[resent a

kind of context diagram by which one can quickly understand the external actors of a

system and the best ways in which they can be used .A Use Case model can be helpful in

project development ,planning and documentation of a systemrequirements.


Use Cases

Actor

Use Case Notation


28/53

MULTI-UTILITY

USE CASE DIAGRAM


SCHEDULE

R

CLOC

KSCREEN SAVER EXIT

DESKTO

P

DISPLAYTIM

E


29/53

MULTI-UTILITY

O-O Analysis - Business Process Layer

Business Object Analysis is a process of understanding the

requirements of a problem and establishing goals of applications. This is easily

accomplished by establishing an use cases. Use cases are scenarios for understanding

system requirements . Apart from developing Use cases ,the uses and the objectives of

the application must be discussed with those who are going to be use it or be affected by

the system .Usually domain experts are the best authorities . Analysis is the tsk of

discovering objects representing the things and concepts.The dynamic model drives the

static model . The Use Case model at the concetual center of application as it drives

everything that follows .

The term actor represents a role that a user plays with respect to the

system.A user may play more than one role.However an actor should represent a single

user.

CLASS DIAGRAM

The class diagram shows how the different entities (people, things, and

data) relate to each other; in other words, it shows the static structures of the system. A

class diagram can be used to display logical classes, which are typically the kinds of

things the business people in an organization talk about rock bands, CDs, radio play;

or loans, home mortgages, car loans, and interest rates. Class diagrams can also be used

to show implementation classes, which are the things that programmers typically deal

with. An implementation class diagram will probably show some of the same classes as

the logical classes diagram. The implementation class diagram won't be drawn with the

same attributes, however, because it will most likely have references to things like

Vectors and Hashmaps.



30/53

MULTI-UTILITY

CLASS DIAGRAM


mouse

-regs,i,o: union

-sregs,s: struct

+initmouse( )

+showmouse( )+findmouse(int,int,int )

+hidemouse( )

+changepointer(int)

+positionmouse(int,int)

draw

# gd,gm: int# maxx,maxy: int

+Draw()

screen

+setMode(int )

+initialize()+writeChar(int,int,char,int)

+writeString(char,int ,int,int)

ItemNode

+ItemNode()

Colorpalette

+blue: char

+green: char+red: char

+reserved: char

+colorpalette()

-hourx,minx,secx: int-houry,miny,secy: int

Clock

+clock()

+getcurrenttime()

+drawhands()

+showclock()

Item

-name,path: char-folder,drive: int

-selected: int

+Item()+isFolder()

+isDrive()

+isSelected()

+getName()+getPath()

+getSelected(int)

-page: int-numpages: int

-numitem: int

-dirname: char

-drive: int-numdrives: int

system

-getKey(int,int)

+getTotal()

+getItem()+close()

+display(int,int)

+getResponse()

+init()

menu

-xpos:int

-ypos:int-choice:int

+menu( )

+getchoice( )

+desktop()

sched

-count,y: int

+menu()+enterinfo()

+viewshed()

+savesched()

+displaysched()+remov()


31/53

MULTI-UTILITY

The above class diagrams show the classes used and their attributes.

The classes used are:

Draw

Mouse

menu

Color palette

Clock

Item

ItemNode

screen

system

sched

SEQUENCE DIAGRAM

Sequence diagrams show a detailed flow for a specific use case or even

just part of a specific use case. They are almost self explanatory; they show the calls

between the different objects in their sequence and can show, at a detailed level, different

calls to different objects.

A sequence diagram has two dimensions: The vertical dimension shows

the sequence of messages/calls in the time order that they occur; the horizontal dimension

shows the object instances to which the messages are sent.

A sequence diagram is very simple to draw. Across the top of your

diagram, identify the class instances (objects) by putting each class instance inside a box.

In the box, put the class instance name and class name separated by a space/colon/space "

: ". If a class instance sends a message to another class instance, draw a line with an open

arrowhead pointing to the receiving class instance; place the name of the message/method

above the line. Optionally, for important messages, you can draw a dotted line with an

arrowhead pointing back to the originating class instance; label the return value above the

dotted line.


CLASS DIAGRAM SHOWING ATTRIBUTES


32/53

MULTI-UTILITY

STATECHART DIAGRAM


EVENT

PERFORMANCE

EVENT

MANAGEMENT

DESKTOP DISPLAY

SECTION

My Computer( ) Explorer( )

Back( )

Scheduler( )

Back( )

Time ( )

Back( )

ScreenSaver( )

Back( )

EXIT


33/53

MULTI-UTILITY

The state chart diagram models the different states that a class can be in

and how that class transitions from state to state. It can be argued that every class has a

state, but that every class shouldn't have a state chart diagram. Only classes with

"interesting" states that is, classes with three or more potential states during system

activity should be modeled.

The notation set of the state chart diagram has five basic elements: the

initial starting point, which is drawn using a solid circle; a transition between states,

which is drawn using a line with an open arrowhead; a state, which is drawn using a

rectangle with rounded corners; a decision point, which is drawn as an open circle; and

one or more termination points, which are drawn using a circle with a solid circle inside

it.

ACTIVITY DIAGRAM

Activity diagrams show the procedural flow of control between two or

more class objects while processing an activity. Activity diagrams can be used to model

higher-level business process at the business unit level, or to model low-level internal

class actions. In my experience, activity diagrams are best used to model higher-level

processes, such as how the company is currently doing business, or how it would like to

do business. This is because activity diagrams are "less technical" in appearance,

compared to sequence diagrams, and business-minded people tend to understand them

more quickly.

An activity diagram's notation set is similar to that used in a statechart

diagram. Like a state chart diagram, the activity diagram starts with a solid circle

connected to the initial activity. The activity is modeled by drawing a rectangle with

rounded edges, enclosing the activity's name. Activities can be connected to other

activities through transition lines, or to decision points that connect to different activities

guarded by conditions of the decision point. Activities that terminate the modeled process

are connected to a termination point (just as in a state chart diagram). Optionally, the

activities can be grouped into swim lanes, which are used to indicate the object that

actually performs the activity.



34/53

MULTI-UTILITY

Join Fork

Branch Merge


Mechanisms used in activity diagrams

Start

End


35/53

MULTI-UTILITY


START

DISPLAYGUI

[ My Computer clicked]

DISPLAY

EXPLORER

yes no

[Scheduler clicked]

[Explorer clicked]

no

DISPLAY

DRIVES

yes

[Drives clicked]

FILES

yes no

yes no

[Clock clicked]

TIME

DISPLAYED

yes no

[ScreenSaver

Timer cond:]

yes no

[ExitClicked]

yes no

STOP

ACTIVITY DIAGRAM

RUN SCREEN

SAVER


36/53

MULTI-UTILITY

COMPONENT DIAGRAM

A component diagram provides a physical view of the system. Its purpose

is to show the dependencies that the software has on the other software components (e.g.,

software libraries) in the system. The diagram can be shown at a very high level, with justthe large-grain components, or it can be shown at the component package level.

Modeling a component diagram is best described through an example.

Figure shows four components: Reporting Tool, Billboard Service, Servlet 2.2 API, and

JDBC API. The arrowed lines from the Reporting Tool component to the Billboard

Service, Servlet 2.2 API, and JDBC API components mean that the Reporting Tool is

dependent on those three components.

A component diagram shows interdependencies of various software components the system

comprises

DEPLOYMENT DIAGRAM

The deployment diagram shows how a system will be physically deployed

in the hardware environment. Its purpose is to show where the different components of

the system will physically run and how they will communicate with each other. Since thediagram models the physical runtime, a system's production staff will make considerable

use of this diagram.



37/53

MULTI-UTILITY

The notation in a deployment diagram includes the notation elements used

in a component diagram, with a couple of additions, including the concept of a node. A

node represents either a physical machine or a virtual machine node (e.g., a mainframe

node). To model a node, simply draw a three-dimensional cube with the name of the node

at the top of the cube. Use the naming convention used in sequence diagrams: [instance

name]: [instance type].

The deployment diagram in Figure shows that the users access the

Reporting Tool by using a browser running on their local machine and connecting via

HTTP over their company's intranet to the Reporting Tool. This tool physically runs on

the Application Server named w3reporting.myco.com. The diagram shows the Reporting

Tool component drawn inside of IBM Web Sphere, which in turn is drawn inside of the

node w3.reporting.myco.com. The Reporting Tool connects to its reporting database

using the Java language to IBM DB2's JDBC interface, which then communicates to the

actual DB2 database running on the server named db1.myco.com using native DB2

communication. In addition to talking to the reporting database, the Report Tool

component communicates via SOAP over HTTPS to the Billboard Service.



38/53

MULTI-UTILITY

OBJECT ORIENTED DESIGN

CLASSES

A class is a blueprint or prototype that defines the variables and the

methods common to all objects of a certain kind. In object-oriented software, it's also

possible to have many objects of the same kind that share characteristics These software

blueprint for objects is called a class. A class variable contains information that is shared

by all instances of the class.

Classes are user-defined data types and behave like the built in types of

programming language. The entire set of data and code of an object can be made a user-

defined data type with the help of Class. Objects are variable of type class.

There are 10 basic classes:

Class Draw

Class mouse

Class menu

Class Colorpalette

Class clock

Class Item

Class ItemNode

Class screen

Class system

Class sched

Class name: draw

Draw() Constructor which initialize and prepares the monitor for displaying

graphics.



39/53

MULTI-UTILITY

Class name: mouse

initmouse() Initializing the mouse by sensing and loading its driver file.

showmouse() Display the mouse pointer on the screen.

findmouse() Locate the current position of mouse pointer and status of mouse button.

hidemouse() Disable mouse activity.

changepointer() Change the shape of mouse pointer.

positionmouse() To position the mouse pointer at a specified location.

Class name: menu

menu() Constructor for menu class

getchoice() For reading user responses to menu buttons.

desktop() For loading and displaying the desktop image

Class name: colorpalette

colorpalette() Constructor for handling the colour table used in bitmap.

Class name: clock

clock() Constructor for clock class

getcurrenttime() Read the current system time from the RTC.

drawhands() Graphical function that draws the clock needles.

showclock() Graphical function that displays the running clock on monitor.

Class name: Item

Item() Constructor for Item class.

Isfolder(0 Verifies a folder.

isDrive() Verifies a drive.

IsSelected() Verifies whether a file is selected.

getName() Read name and path of file.

getPath() Pass the path to copying function.

getSelected() Mark a file as selected for copying.

Class name: ItemNode

ItemNode() Constructor.

Class name: sched

menu() For showing the scheduler option

enterinfo() To add a new schedule



40/53

MULTI-UTILITY

viewsched() For verifying existing schedule

savessched() For storing newly added schedule

displaysched() For showing the currently specified schedule

remov() For raising the existing schedule from disk

OBJECTS

Objects are the basic run-time entities in an object oriented system. Objects are created

using classes. Object is an instance of a class.The member functions of a class can be

invoked only through an object of the class.

For example: For class mouse, object used is M and it is created in

getchoice ( ) function.

DATA ABSTRACTION AND ENCAPSULATION

The wrapping up of data and functions into a single unit called class is

known as encapsulation.The data is not accessible to outside world,only those functions

which are wrapped in the class can access it.These functions provide the interfacebetween objects data and the program.This insulation of the data from direct access by

the program is called datahiding.

Abstraction refers to the act of representing essential features

without including background details. Classes use the concept of abstraction and are

defined as a list of attributes and functions to operate on these attributes.

CONTAINERSHIP

Containership is defined as the ability of one object or class to contain other

objects including other containers.

Unsigned int menu :: getchoice ()



41/53

MULTI-UTILITY

CONSTRUCTORS

A constructor is a special member function which initializes the objects of its class.

It will have the same name as its class. It is called constructor because it constructs the

values of data members of the class.

class Draw

{

protected:

int gd, gm, maxx, maxy;

public:

Draw ()

{

gd = DETECT;

initgraph (&gd, &gm,"e:\\software\\tc\\bgi");

maxx = getmaxx ();

maxy = getmaxy ();

}

};

Constructor Draw () is used inside the class draw as shown above.



42/53

MULTI-UTILITY

SYSTEM TESTING



43/53

MULTI-UTILITY

SYSTEM TESTING

System testing is a critical aspect of Software Quality Assurance and

represents the ultimate review of specification, design and coding. Testing is a process of

executing a program with the intent of finding an error. A good test is one that has a

probability of finding an as yet undiscovered error. The purpose of testing is to identify

and correct bugs in the developed system. Nothing is complete without testing. Testing is

the vital to the success of the system.

In the code testing the logic of the developed system is tested. For this

every module of the program is executed to find an error. To perform specification test,

the examination of the specifications stating what the program should do and how it

should perform under various conditions.

Unit testing focuses first on the modules in the proposed system to

locate errors. This enables to detect errors in the coding and logic that are contained

within that module alone. Those resulting from the interaction between modules are

initially avoided. In unit testing step each module has to be checked separately.

System testing does not test the software as a whole, but rather than

integration of each module in the systems. The primary concern is the compatibility of

individual modules. One has to find areas where modules have been designed with

different specifications of data lengths, type and data element name.

Testing and validation are the most important steps after the

implementation of the developed system. The system testing is performed to ensure that

there are no errors in the implemented system. The software must be executed several

times in order to find out the errors in the different modules of the system.

Validation refers to the process of using the new software for the

developed system in a live environment i.e., new software inside the organization, in

order to find out the errors. The validation phase reveals the failures and the bugs in the

developed system. It will be come to know about the practical difficulties the system

faces when operated in the true environment. By testing the code of the implemented

software, the logic of the program can be examined. A specification test is conducted to



44/53

MULTI-UTILITY

check whether the specifications stating the program are performing under various

conditions.

Apart from these tests, there are some special tests conducted which

are given below:

1. Peak Load Tests this determines whether the new system will handle the volume

of activities when the system is at the peak of its processing demand. The test has

revealed that the new software for the agency is capable of handling the demands at the

peak time.

2. Storage Testing this determines the capacity of the new system to store

transaction data on a disk or on other files. The proposed software has the required

storage space available, because of the use of a number of hard disks.

3. Performance Time Testing this test determines the length of the time used by the

system to process transaction data.

SYSTEM TESTING

The newly designed system should be in the working order

but in reality, each should work independently. Now is the time to pull all into

one system and test it to determine whether it meets the user requirements.

System testing is executing a program to check logic changes made in it and

with the intention of finding errors-making the program fail.

We have carefully verified the working of the MULTI-

UTILITY software by keeping in mind all these aspects and found that it

produced satisfactory results.



45/53

MULTI-UTILITY

PROGRAM TESTING

Before implementation, the designed system should be tested with

row data to ensure that all modules of the system were tested using the

following strategies.

Unit testing

System testing

Unit testing:

Each of the modules were developed and tested

independently and where the following considerations were made:-

The module interface tested to check the flow of

information.

Boundary conditions are tested.

All error-handling paths are checked.

All-important path through the control structure are

exercised to ensure each execution at least once.

System testing:

Integration testing was done to variety the co-existence of the

modules and the forms involved. Bottom-up integration strategy was used.

After the unit testing they were integrated from bottom to up by combining the

clusters. Finally, when all the modules were developed and integrated them

were tested with the data, which were provided by some individuals as well as

the members involved in visualizing this concept.

The MULTI -UTILITY is found to be working properly with

Microsoft Windows as well as MS DOS operating systems. Numerous trial runs were

utilized for measuring the reliability of the software and we obtained pretty good results.



46/53

MULTI-UTILITY

OUTPUT SCREENS



47/53

MULTI-UTILITY

SAMPLE OUTPUTS

THE MAIN DESKTOP WINDOW



48/53

MULTI-UTILITY

THE CLOCK WINDOW



49/53

MULTI-UTILITY

THE SCHEDULER WINDOW



50/53

MULTI-UTILITY

CONCLUSION & FUTURE

ENHANCEMENTS



51/53

MULTI-UTILITY

CONCLUSION & FUTURE ENHANCEMENTS

We have been successful in developing a software that fulfills the

proposed goals. However, we do realize the limitations of it. Despite our best efforts, the

explorer like interface of the software is not at all appealing as like those found in

Microsoft Windows or Linux operating systems. Additionally it is unable to remove files

from drives or implement an utility like the Recycle Bin. Moreover, a real time running

clock could have been provided for making the interface more beautiful. Another

drawback is that this utility is often seem to be too slow in responding to directory search

calls. In spite of all these drawbacks, the capability of the software to explore the

computer hardware without memorizing commands makes it worth for an user.

The developed software can be enhanced in future to incorporate the many

desirable features. As with all contemporary graphical user interfaces, we need to have

provisions for changing the appearance of the main desktop window by providing

different wallpapers to it. As said earlier, the disk management capabilities also need

many new additions. We have taken care to design the objects within the software to

accommodate such alterations in future easily. The usage of modern graphical, searching

and sorting algorithms audio would surely improve the overall efficiency of the software.

With these additions, we are pretty sure that our software would secure better scores in

even the toughest benchmarking criteria.



52/53

MULTI-UTILITY

BIBLIOGRAPHY



53/53

MULTI-UTILITY

B IBLIOGRAPHY

[Ellis, 1989] Margaret A.Ellis and Bjarne Stroustrup. The

Annotated C++ Reference Manual,Addison-Wesley

[Schildt, 1991] Herbert Schildt. C++, The Complete

Reference, Osborne McGraw-Hill

[Kanetkar, 2002] Yashavant Kanetkar. Graphics Under C,BPB Publications India

[Rumbaugh, 1999] Rumbaugh, James, Ivar Jacobson, Grady

Booch. The Unified Modeling Language

Reference Manual, Addison-Wesley

Longman

WEB Sites

1. www.codeguru.com

2. www.aaroncake.com

3. www.devsource.com

4. www.webopedia.com

5. www.cs.cmu.edu
http://www.devsource.com/http://www.webopedia.com/http://www.devsource.com/http://www.webopedia.com/

MU for DOS doc

Documents

Transcript of MU for DOS doc