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

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 the work 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 member involved 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 work details. The person, who is updating the project, after collecting all the reports, updates the project status. 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 getting reports from subordinates weekly, based on these reports update the project status. Whenever the administrator log into the system he/she should get all the employees details as well as the work status of 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 and corresponding time period to complete it. After every week the employee should send a report containing his work status. Whenever the employee log into the system he/she should get only the task assigned to him/her and interfaces regarding to his task. He is not permitted to involve into others details and reports generated by other employees.

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

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

1. Introduction: 1.1 Purpose: The purpose of this document is to describe the analysis part of Automation 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 members and 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.

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 is through 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.

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.

Function login logout createtask Assign_emp allocate_task view_status modifytask deletetask status_of_task send_report update_task update_status

Input Username,password

Process It allows the user to login the system It allows the user to logout the system It will create a task Assign an employee to a task Allocate the task to to employee Administrator can view the status Task modification will be done Task will be deleted from the list of tasks An employee can view his task status Employee send a report about the task Administrator updates the task Administrator update project status

Output Success message taskid Success message Success message

Employeeid Tasked taskid taskid taskid taskid taskid projectid

Success message

Success message Success message Success message

3.2.2 Functions:

3.3 Performance requirements: The system should support minimum ten terminals with LAN connection. The number of simultaneous users to be supported must be ten. The response time for each report should be less than 100 milliseconds. Immediately after submitting the report a successful/unsuccessful message should come. 3.4 Design constraints: 3.4.1 Software constraints: The system should possess windows operating system with processor 200 Mhz with memory 256Mb.

3.4.2 Hardware constraints: The system has no specific hardware constraints.

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 of objects. 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.

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 of what the 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 of how the system is to be built.

RATIONAL ROSE SOFTWARE

1. Introduction
Rational Rose is an object-oriented Unified Modeling Language, software design tool intended for modeling 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 code generation 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 factors

1. 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.

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

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 architectural blueprints, including elements such as: 1. Actors 2. Business processes 3. (logical) Components 4. Activities 5. Programming language statements 6. 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

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 conceptual elements. 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: Collaboration

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

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 to accomplish a specific task.

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

Grouping things: Grouping things can be defined as a mechanism to group elements of a UML model together. There is only 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 of UML 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

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 the other one.

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

Generalization: Generalization can be defined as a relationship which connects a specialized element with a generalized 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 element describes some responsibility which is not implemented and the other one implements them. This relationship 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 other elements are used to make it a complete one. UML includes the following nine diagrams and the details are described in the following chapters. 14

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

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

USE CASE DIAGRAMS:

17

< < inc ludes >>

allocatetas k

m anagetas k adm inis trator

<< inc ludes > >

getdetails

updatetas k

em ploy ee s ubm it

18

generatetask

project

modifytask

updateproject

19

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

CLASS DIAGRAM:

generalization

<<persistent>> User username : string password : string login() logout()

classes

<<persistent>> Administrator allocate_task() 1 view_status() update_task() 1 <<use>> 1..10

<<persistent>> Employee eno : number date_of_assign : string date_of_completion : string status_of_task() send_report()

realization 1 <<persistent>> Project pid : number tid : number createtask() modifytask() deletetask() assign_emp() update_status() dependency relationship with multiplicities

21

SEQUENCE DIAGRAM:

a : administrator

p : project

e : employee

createtask() objects

allocate_task(tid)

status_of_task(tid)

messages send_report(tid) update_task(tid) modifytask(tid) deletetask(tid) update_status()

22

COLLOBARATION DIAGRAM:

3: status_of_task(tid)

2: allocate_task(tid) a: Administrator 4: send_report(tid) e: Employee

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

1: createtask()

p: Project

23

ACITIVITY DIAGRAM:

24

Adm inistrator

swim lin
Modeling Component View and Deployment View
25

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

ARTIFACT DIAGRAM:

admin.java employee.java project.java

user.db admin.db employee.db project.db

<<artifact>> Automationofproject.exe

admin.exe employee.exe project.exe

27

DEPLOYEMENT DIAGRAM:

< < proc ess or> > S erver Deploys us er.db adm in.db em ployee.db projec t.ex e projec t.db

P roces sor: *200 M hz M em ory: *256 M b < < proces sor> > Client Deploy s adm in.ex e em ploy ee.ex e

P roces s or: *100 M hz M em ory : *128 M b

28

29

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

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