automation of project development

8/3/2019 Automation of Project Development

1/31

FIED MODELING LANGUAGE

CONTENTS

1. Abstract

2. Software Requirement Specification

3. Object Oriented System Development

4. Rational Rose Software

5. Unified Modeling Language

6. Modeling Use Case View

a. Use Case Diagrams

7. Modeling Logical View

a. Class Diagrams

b. Sequence Diagrams

c. Collaboration Diagrams

8. Modeling Component View

a. Component Diagram

9. Modeling Deployment View

a. Deployment Diagram

10. Conclusion

1


2/31

11. Bibliography

AUTOMATION OF PROJECT DEVELOPMENT

Abstract:The system to be developed is to update the project status based on the input about the status of thework provided by each individual involved in that project.

Overview:

The overview of this project can be described in terms of the reports generated by each memberinvolved in that particular project.Based on the scope of the project a team of members can be assigned to that project. Each of the team

members is given a task and corresponding time to complete that task.After a regular period of time, each team member should generate a report containing the workdetails. The person, who is updating the project, after collecting all the reports, updates the projectstatus.This project mainly consists of two modules. The two modules are

i. Administrator module

ii. Employee module.

Administrator module:

This administrator module is mainly concerned with allocating the task to employees and gettingreports from subordinates weekly, based on these reports update the project status. Whenever theadministrator log into the system he/she should get all the employees details as well as the work statusof each individual task as a report.

Employee module:The second module involved in this project is the employee module. An employee is given a task andcorresponding time period to complete it. After every week the employee should send a reportcontaining his work status. Whenever the employee log into the system he/she should get only thetask assigned to him/her and interfaces regarding to his task. He is not permitted to involve into othersdetails and reports generated by other employees.

2


3/31

The purpose of this document is to describe the overview and analysis of the project so that the codercan feel free to code.

SOFTWARE REQUIREMENTS SPECIFICATION ( SRS)

1. Introduction:

1.1 Purpose:

The purpose of this document is to describe the analysis part ofAutomation of project development

so that it is easy for the designer to design the system and for the coder to implement it as well as for

the tester to prepare the test cases and test the system.

1.2 Scope:

This document is the only one that describes the requirements of the system.it is meant for use by the

developers and will be the basis for validating the final delivered system.

1.3 Definitions:

Administrator: An administrator is the person, who can monitor the entire project including the

employees.

Employee: An employee is the person, who can do the work assigned to him and must submit the

work status to the administrator. He is not allowed to see others reports as well as administrators

details.

2. Overall description:

2.1 Product perspective:

This product is a part of a large system and is independent to other parts.

2.2 Product functions:

In a software company, there are number of projects. Each project is assigned to a group of membersand an administrator to monitor it. Each team member is given a task and time period to complete that

task. The system is to update the project status by using the reports send by each team member. The

administrator after updating, send it to the higher authority in the form of a report.

3


4/31

2.3 User characteristics:

The main users of this system will be technical experts.

2.4 General assumptions and dependencies:

The project is a small one with a team of ten members including the administrator. Each team

member should send a report to the administrator for every week. The administrator monitors all the

employees.

3. Specific requirements:

3.1External interface requirements:

3.1.1 User interface:

There are mainly two user interfaces. One for the team member other for the administrator. Each of

these interfaces is distinct from one another. Each interface contains a set of fields to fill up.

3.1.2 Hardware interfaces:

The system has no specific hardware interface requirements.

3.1.3 Software interfaces:

The system must use SQL server as its database component. Communication with database isthrough ODBC connections.

3.1.4 Communication interfaces:

The system must use google talk as its communication interface so that the employees can

communicate and share their views with each other.

3.2 Functional requirements:

3.2.1 Inputs and outputs:

The system has 10 inputs and one output. Each input contains the fields like employee name, ID,task, total time, working hours, extra time required, lines of code, number of days worked, reporting

time.

4


5/31

The employee or team member should fill up all the fields and send it to the administrator. The

administrator after collecting all the reports must update total project metrics/measurements and send

it to the higher authority as an output. The output contains the fields like administrator name, ID,

project name, project status etc.

3.2.2 Functions:

3.3 Performance requirements:The system should support minimum ten terminals with LAN connection. The number ofsimultaneous users to be supported must be ten. The response time for each report should be less than100 milliseconds. Immediately after submitting the report a successful/unsuccessful message shouldcome.3.4 Design constraints:

3.4.1 Software constraints:

The system should possess windows operating system with processor 200 Mhz with memory256Mb.

5

Function Input Process Output

login Username,password It allows the user to login the system Success message

logout It allows the user to logout the system

createtask It will create a task taskid

Assign_emp Employeeid Assign an employee to a task Success message

allocate_task Tasked Allocate the task to to employee Success message

view_status Administrator can view the status

modifytask taskid Task modification will be donedeletetask taskid Task will be deleted from the list of tasks Success message

status_of_task taskid An employee can view his task status

send_report taskid Employee send a report about the task Success message

update_task taskid Administrator updates the task Success message

update_status projectid Administrator update project status Success message


6/31

3.4.2 Hardware constraints:

The system has no specific hardware constraints.

6


7/31

OBJECT ORIENTED SYSTEM DEVELOPMENT

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system

as a group of interacting objects. Each object represents some entity of interest in the system being

modeled, and is characterized by its class, its state (data elements), and its behavior. Various models

can be created to show the static structure, dynamic behavior, and run-time deployment of these

collaborating objects. There are a number of different notations for representing these models, such as

the Unified Modeling Language (UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional

requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce

implementation specifications. OOA focuses on what the system does, OOD on how the system does

it.

Object-oriented systems

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

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

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

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

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

object.

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

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

Object-oriented analysis

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

model of the information that exists in the area being analyzed. Analysis models do not consider any

implementation constraints that might exist, such as concurrency, distribution, persistence, or how the

system is to be built. Implementation constraints are dealt during object-oriented design (OOD).

Analysis is done before the Design.

7
http://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Object_(computer_science)http://en.wikipedia.org/wiki/Object_(computer_science)


8/31

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

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

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

analyzed separately.

The result of object-oriented analysis is a description ofwhatthe system is functionally required to

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

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

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

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

Object-oriented design

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

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

technological or environmental constraints, such as transaction throughput, response time, run-time

platform, development environment, or programming language.

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

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

8


9/31

RATIONAL ROSE SOFTWARE

1. Introduction

Rational Rose is an object-oriented Unified Modeling Language, software design tool intended formodeling object oriented entities and helps for effective Object Oriented Analysis and Design which

is the sub goal for Object Oriented System Development.

2. What is Rational Rose?

Rational Rose is commercial case-tool software. It supports two essential elements of modern

software engineering: component based development and controlled iterative development. Models

created with Rose can be visualized with several UML diagrams. Rose also supports for the codegeneration and reverse engineering of the Object Oriented Programming Language.

3. How was the tool used?

The tool was used to create the packet hierarchy, structure and dependencies of classes, state diagram

and an example of the control flow (sequence diagram) of the project.

4. Summary of the Rational Rose

Positive factors

1. The tool itself was quite easy to install.

2. The creation of the different diagrams can be learned quite fast.

3. Code generation is simple.

Negative factors1. At first the tool seems to be quite complex.

2. Some minor bugs were found.

3. Layout manager could have been a bit more effective.

9


10/31

Conclusion

The tool is useful. A little bit learning is needed to figure out the basic features of the tool. Round-trip

engineering was quite easy and definitely helps to keep model and source codes up to date. For a

small project this tool may be a bit too powerful meaning that the learning may take more time that

is relatively beneficial in a small project.

10


11/31

UNIFIED MODELING LANGUAGE

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field

of software engineering.

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document

the artifacts of an object-oriented software intensive system under development. UML offers a

standard way to visualize a system's architecturalblueprints, including elements such as:

1. Actors

2. Business processes

3. (logical) Components

4. Activities

5. Programming language statements6. Database schemas, and

7. Reusable software components.

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:

1. Things

2. Relationships

3. Diagrams

Things are the abstractions that are first-class citizens in a model; relationships tie these things

together; diagrams group interesting collections of things.

Things in the UML

There are four kinds of things in the UML:

1. Structural things

2. Behavioral things

3. Grouping things

4. Annotational things

11
http://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Blueprinthttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Object-orientedhttp://en.wikipedia.org/wiki/Blueprint


12/31

These things are the basic object-oriented building blocks of the UML. You use them to write well

formed models.

Structural things:

The Structural things define the static part of the model. They represent physical and conceptualelements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

12

Collaboration


13/31

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among elements toaccomplish a specific task.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the sequenceof states an object goes through in response to events. Events are external factors responsible for statechange.

Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together. There isonly one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments ofUML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc. of an UML element.

13


14/31

Relationship:

Relationship is another most important building block of UML. It shows how elements are associated

with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects theother one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes howmany objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with ageneralized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected. One elementdescribes some responsibility which is not implemented and the other one implements them. Thisrelationship exists in case of interfaces.

UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are

used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the otherelements are used to make it a complete one.

UML includes the following nine diagrams and the details are described in the following chapters.

14


15/31

1. Class diagram

2. Object diagram

3. Use case diagram

4. Sequence diagram

5. Collaboration diagram

6. Activity diagram

7. State chart diagram

8. Deployment diagram

9. Component diagram

15


16/31

Modeling Use-Case View

To provide a basis for planning the technical contents of iterations, an architectural view called the

use-case view is used in the Requirements discipline. There is only one use-case view of the system,

which illustrates the use cases and scenarios that encompass architecturally significant behavior,

classes, or technical risks. The use-case view is refined and considered initially in each iteration.

The use-case view shows an architecturally significant subset of the use-case model, a subset of the

use cases and actors.

16


17/31

USE CASE DIAGRAMS:

17


18/31

allocatetask

managetask

getdetails

administrator

updatetask

employeesubmit

18


19/31

generatetask

modifytaskproject

updateproject

19


20/31

Modeling Logical View

To provide a basis for understanding the structure and organization of the design of the system, an

architectural view called the Logical View is used in the Analysis & Design workflow. There is only

one logical view of the system, which illustrates the key use-case realizations, subsystems, packages

and classes that encompass architecturally significant behavior. The logical view is refined during

each iteration.

The logical view shows an architecturally significant subset of the design model, i.e. a subset of the

classes, subsystems and packages, and use-case realizations.

20


21/31

CLASS DIAGRAM:

User

username : string

password : string

login()logout()

Project

pid : number

tid : number

createtask()

modifytask()

deletetask()assign_emp()update_status()

1

1

classesgeneralization

dependencyrelationship with

multiplicities

Employee

eno : number

date_of_assign : string

date_of_completion : string

status_of_task()

send_report()

Administrator

allocate_task()

view_status()

update_task()

1 1..10

realization

21


22/31

SEQUENCE DIAGRAM:

a : administrator p : project e : employee

allocate_task(tid)status_of_task(tid)

send_report(tid)

update_task(tid)

modifytask(tid)

deletetask(tid)

update_status()

objects

messages

createtask()

22


23/31

COLLOBARATION DIAGRAM:

a :

Administrator

p :

Project

e :

Employee

3: status_of_task(tid)

1: createtask()

5: update_task(tid)6: modifytask(tid)7: deletetask(tid)

8: update_status()

2: allocate_task(tid)

4: send_report(tid)

23


24/31

ACITIVITY DIAGRAM:

24


25/31

Administra

swi

Modeling Component View and Deployment View25


26/31

To provide a basis for understanding the physical distribution of the system across a set of processing

nodes, an architectural view called the deployment view is used in the Analysis & Design workflow.

The deployment view (one of five views - see below) illustrates the distribution of processing across a

set of nodes in the system, including the physical distribution of processes and threads. The

deployment view is refined during each iteration.

Example:

The deployment view shows the physical distribution of processing within the system.

26


27/31

ARTIFACT DIAGRAM:

admin.java

employee.java

project.java

user.db

admin.dbemployee.dbproject.db

admin.exeemployee.exeproject.exe

27

Automationofproject.exe


28/31

DEPLOYEMENT DIAGRAM:

Server

Client

Deploys

user.db

admin.db

employee.db

project.exe

project.db

Processor:

*200 Mhz

Memory:

*256 Mb

Deploys

admin.exe

employee.exe Processor:

*100 Mhz

Memory:

*128 Mb

28


29/31

29


30/31

Conclusion

The projects that are using the object oriented approach in the SDLC phases of Analysis and Design,

the coders feel at most comfortable to develop / code the components that are analyzed and designed

in the class, sequence, component diagrams.

The life cycle of an object can be easily visualized by observing the Object, Sequence diagrams.

Henceforth a new team member who joins the coding team at any stage can easily cope up with the

project work.

30


31/31

Bibliography

The Unified Modeling Language User Guide Grady Booch, James Rumbaugh, Ivar

Jacobson.

Object Oriented Analysis and Design with applications Grady Booch.

Rational Rose Real Time Tutorials and Documentations.

Rational Software Corporation Modeling Language Guide.

31

automation of project development

Documents