Upload
venkatesh-hanumandla
View
225
Download
0
Embed Size (px)
Citation preview
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
6/31
3.4.2 Hardware constraints:
The system has no specific hardware constraints.
6
8/3/2019 Automation of Project Development
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/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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/Blueprint8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
17/31
USE CASE DIAGRAMS:
17
8/3/2019 Automation of Project Development
18/31
allocatetask
managetask
getdetails
administrator
updatetask
employeesubmit
18
8/3/2019 Automation of Project Development
19/31
generatetask
modifytaskproject
updateproject
19
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
24/31
ACITIVITY DIAGRAM:
24
8/3/2019 Automation of Project Development
25/31
Administra
swi
Modeling Component View and Deployment View25
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
27/31
ARTIFACT DIAGRAM:
admin.java
employee.java
project.java
user.db
admin.dbemployee.dbproject.db
admin.exeemployee.exeproject.exe
27
Automationofproject.exe
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
29/31
29
8/3/2019 Automation of Project Development
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
8/3/2019 Automation of Project Development
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