B.E. 3/4 - II Semester BIT- 381
OOSD LAB
List of Experiments Prescribed by Osmania University Students have to perform the following OOSD steps on the Given Case Study.
Use case Modeling
Structural Modeling
Behavioral Modeling
Architectural Modeling
The list of Experiments:
1. Use case Diagram 2. Class Diagram 3. Sequence Diagram 4. Collaboration Diagram 5. State Diagram 6. Activity Diagram 7. Component Diagram 8. Deployment Diagram List of innovative experiments (If any)
9. Selection of a Case Study – Problem Statement. 10. Software Requirement Specification. Design based Experiments To design a case study like Road Transport Authority system by using the following UML Diagrams:
Class Diagram Sequence Diagram Collaboration Diagram State chart Diagrams
1
Usecase Diagrams Deployment Diagrams
OOSD LAB CONTENTS S.NO
Name of the Experiment
Page no.
The students have to perform the Use case Modeling step on the Given case study by using:
1.
Use case Diagrams.
3
The students have to perform the Structural Modeling step on the Given case study by using:
2.
Class Diagrams
9
3.
Sequ Sequen ence ce Diag Diagra rams ms
14
4.
Coll Collab abor orati ation on Diag Diagram ramss
21
The students have to perform the Behavioral Modeling step on the Given case study by using:
5.
Acti Activi vity ty Diag Diagra rams ms
24
6.
Stat Statee Diag Diagra rams ms
29
The students have to perform the Architectural Architectural Modeling step on the Given case study by using:
7.
Comp Compon onen entt Diag Diagra rams ms
33
8.
Deplo Deploym ymen entt Diag Diagram ramss
36
9*
Assigning of a Case Study - Example: ONLINE EAMCET EXAM.
10*
Writing of Problem Statement to the given Case Study.
39
Software Requirement Specification.
40
* Innovative Experiments
*d
Class Diagram
44
*d
Sequence Diagrams
48
*d
Collaboration Diagrams
55
*d
State chart Diagrams
59
*d
Usecase Diagrams
62 2
Usecase Diagrams Deployment Diagrams
OOSD LAB CONTENTS S.NO
Name of the Experiment
Page no.
The students have to perform the Use case Modeling step on the Given case study by using:
1.
Use case Diagrams.
3
The students have to perform the Structural Modeling step on the Given case study by using:
2.
Class Diagrams
9
3.
Sequ Sequen ence ce Diag Diagra rams ms
14
4.
Coll Collab abor orati ation on Diag Diagram ramss
21
The students have to perform the Behavioral Modeling step on the Given case study by using:
5.
Acti Activi vity ty Diag Diagra rams ms
24
6.
Stat Statee Diag Diagra rams ms
29
The students have to perform the Architectural Architectural Modeling step on the Given case study by using:
7.
Comp Compon onen entt Diag Diagra rams ms
33
8.
Deplo Deploym ymen entt Diag Diagram ramss
36
9*
Assigning of a Case Study - Example: ONLINE EAMCET EXAM.
10*
Writing of Problem Statement to the given Case Study.
39
Software Requirement Specification.
40
* Innovative Experiments
*d
Class Diagram
44
*d
Sequence Diagrams
48
*d
Collaboration Diagrams
55
*d
State chart Diagrams
59
*d
Usecase Diagrams
62 2
*d
Deployment Diagrams
66
1. Use case diagrams AIM: To identify actors, use cases and relationships for representing functional
Requirement of system using Use case diagrams. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: Actor:
Actors represent system users. They help delimit the system and give a clearer picture of what the system should do. do. It is important to note that an actor interacts with, but has no control over the use cases. An actor is someone or something that: ·
Interacts with or uses the system
·
Prov Provid ides es inp input to and and rec recei eive vess in inform format atio ion n fro from m th the sy system stem
·
Is exte extern rnal al to the the sys syste tem m an and has has no co contro ntroll ove overr th the use use case casess
Actors are discovered by examining: ·
Who directly uses the system?
·
Who is responsible for for maintain aining the system? em?
·
External ha hardware used by the system
·
Other sy systems th that need to to in interact with th the sy system
The needs of the actor are used to develop use cases. This insures that the system will be that the user expected.
3
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case diagram. Naming
The name of the actor is displayed below the icon. Additional information about the actor can be viewed in the Use-Case Specification which is identical to a Class Specification with the addition of the Stereotype field set to actor. Use cases: A use case is a high-level piece of functionality that the system will provide
In its simplest form, a use case can be described as a specific way of using the system from a user’s (actor’s) perspective. A more detailed description might characterize a use case as:
·
A pattern of behavior the system exhibits
·
A sequence of related transactions performed by an actor and the system
·
Delivering something of value to the actor
Use cases provide a means to: ·
capture system requirements
·
communicate with the end users and domain experts
·
test the system
Use cases are best discovered by examining the actors and defining what the actor will be able to do with the system. Since all the needs of a system typically cannot be covered in one use case, it is usual to have a collection of use cases. Together this use case collection specifies all the ways of using the system.
4
By looking at the use cases, the customer can see what functionality will be provided, and can agree to the system scope before the project goes any further
Graphical Depiction
The basic shape of a use case is an ellipse: Naming
A use case may have a name, although it is typically not a simple name. It is often written as an informal text description of the actors and the sequences of events between objects. Use case names often start with a verb. For example, names of possible use cases for an ATM machine might include Dispense Cash or Transfer Funds. The name of the use case is displayed below the icon. Additional information about a use case can be viewed in the Use-Case specification.
Relationships There are four types of relationships 1. Association 2. Includes relationship 3. Extends relationship 4. Generalization relationship. You can draw an Association relationship from a use case to an actor. You can draw a Generalize relationship between two use cases and /or two actors You can draw a Dependency relationship between two use cases. Association Relationship
The relationship between an actor and a use case is an association relationship . In UML, association relationships are diagrammed using an arrow:
5
Include Relationship
An included relationship allows one use case to use the functionality provided by another use case. This relationship can be used in one of two cases. First, if two or more use cases have a large piece of functionality that is identical, this functionality can be split into its own use case. Each of the other use cases can then have an include relationship with this new use case. The second case where an include relationship is helpful is a situation in which a single use case has an unusually large amount of functionality. An include relationship can be used to model two smaller use cases instead. Includes relationships are shown in Rational Rose with dashed arrows and the word <>
3. Extend Relationship
In contrast, an extend relationship allows one use case the option to extend the functionality provided by another use case. It is very similar to an include relationship, because in both of these types of relationships, you separate some common functionality into its own use case. In UML, the extend relationship is shown as a dashed arrow with the word <>
6
4. Generalization Relationship A generalization relationship is used to show that several actors or use cases have some some comm common onali ality ty.. For For exam exampl ple, e, you you may may have have two two type typess of cust custom omers ers:: corporate customers and individual customers.
If both types of customers use the same use cases, it's probably not necessary to show an actor generalization. If both types use the same use cases, but slightly differently, it still isn't worth including the generalization. The slight differences are documented in the flow of events Flow of Events
The purpose of the flow of events is to document the flow of logic through the use case. This document will describe in detail what the user of the system will do and what the system itself will do. The flow of events typically includes:
A brief description
Preconditions
Primary flow of events
Alternate flow of events
Post-conditions
Description
Each use case should should include a short description description that explains explains what the use case will do The description should be short and to the point, but should include the different types of users who will be executing the use case and the end result the user expects to achieve through the use case.
7
Preconditions
The preconditions for a use case list any conditions that have to be met before the use case can start at all. For example, a precondition might be that another use case has been executed or that the user has the necessary access rights to run the current use case. Not all use cases will have preconditions. Primary and Alternate Flow of Events
The specific details of the use case are described in the primary and alternate flow of events. The flow of events describes, step-by-step, what will happen to execute the functionality in the use case. The flow of events focuses on what the system will do not how it will do it, and is written from the user's perspective. The primary and alternate flow of events includes:
How the use case starts
The various paths through the use case ca se
The normal, or primary, flow through the use case
Any deviations from the primary flow, known as
alternate flows, through the use case
Any error flows
How the use case ends
Post-Conditions
Post-conditions are conditions that must always be true after the use case has finish finished ed execut executing ing.. Like Like precon precondit dition ions, s, post-c post-cond onditi itions ons can be used used to add information about the order in which the use cases are run. If, for example, one use case must always be run after another use case, you can document this in the post-conditions. Not every use case will have post-conditions.
USECASE DIAGRAM:
8
Use case Diagram is graphical view of some or all of the actors, use cases, their interactions identified for a system
Exercise 3:
9
1. 2. 3. 4. 5. 6. 7. 8.
Identify actors for your system. For each actor write the documentation. Identify use cases for your system. Document the use cases. Write use case specification for each use case identified. Link use case documents to Use cases in Rational Rose. Identify use case relationships Draw a Main and sub use case diagrams for you system.
10
1. Class Diagram AIM: To identify different classes involve in the system and relationships among
these classes to draw class diagram with all options. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented systems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Graphically, a class diagram is a collection of vertices and arcs. A class diagram is a picture for describing generic descriptions of possible systems. Class diagrams and collaboration diagrams are alternate representations of object models. Class diagrams contain classes and object diagrams contain objects, but it is possible to affix classes and objects when dealing with various kinds of metadata, so the separation is not rigid. Class diagrams are more prevalent than object diagrams. Normally you will build class diagrams plus occasional object diagrams illustrating complicated data structures-or message-passing structures. Class diagrams contain icons representing classes, interfaces, and their relationships. You can create one or more class diagrams to depict the classes at the top level of the current model; such class diagrams are themselves contained by the top level of the current model. You can also create one or more class diagrams to depict classes contained by each package in your model; such class diagrams are themselves contained by the package enclosing the classes they depict; the icons representing logical packages and classes in class diagrams We can change properties or relationships by editing the specification or modifying the icon on the diagram. The associated diagrams or specifications are automatically updated.
11
Class diagrams are the backbone of almost every object oriented method including UML. Class diagrams describe the static structure of a system. Contents: Class Diagrams commonly contain the following things: Classes Interfaces Collaborations Dependency, generalization and association relationships 2. Classes & Interfaces: Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically a class is rendered as a rectangle, usually including its name, attributes and operations, as shown below.
Window Origin Size Open () Close () Display () Interface:
An interface is a collection of operations that specify a service of a class or component. An interface describes the externally visible behavior of that element. Graphically the interface is rendered as a circle together with its name.
ISpelling
12
The various classes in our class diagram are:
student system database faculty Manager
DIAGRAM:
Exercise: 1) Discover the initial – cut classes – Entity, Boundary and Control Classes. 2) Document the classes identified above and observe whether you have given appropriate name and definition. 3) Group the identified classes into packages. 4) Write Main class diagram of the logical view model. 5) Write Main class diagram for each package identified.
13
2.
Sequence Diagram
AIM: To analyze major functionalities and represent communication among objects
with time bound for each operation. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. This type of diagram is best used during early analysis phases in design because they are simple and easy to comprehend. Sequence diagrams are normally associated with use cases. Sequence diagrams are closely related to collaboration diagrams and both are alternate representations of an interaction. There are two main differences between sequence and collaboration diagrams: sequence diagrams show time-based object interaction while collaboration diagrams show how objects associate with each other. A sequence diagram has two dimensions: typically, vertical placement represents time and horizontal placement represents different objects. The following tools located on the sequence diagram toolbox enable you to model sequence diagrams:
Object
Message Icons
Focus of Control
Message to Self
Note
Note Anchor
14
A sequence diagram consists of the following sequence diagram behavioral elements.
Element and its description
Symbol
Object: The primary element involved in a sequence diagram is an object—an instance of a class. A Sequence diagram consists of sequence of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the “.” Is the object name and to its right is the class name. Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a sequence diagram, you can represent simple messages, Special messages to create or destroy objects, and message responses.
The steps involved in creating a Sequence are:
Identify objects.
Identify actors.
Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term that represents some concrete, real-world thing. Examples of objects are: airplane, a flight, a passenger, a piece of luggage, or a ticket. Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of events. Another good place to look is in the scenario documents. A scenario is a specific instance of a flow of events.
15
Lifeline
It specifies the existence of the Object. Each object has a lifeline , drawn as a vertical dashed line below the object. The lifeline begins when the object is instantiated and ends when the object is destroyed. Focus of Control
In a Sequence diagram, you have the option of showing the focus of control, which lets you know which object has control at a particular point in time. A small vertical rectangle represents the focus of control. Messages
A message is a communication between objects in which one object (the client) asks another object (the supplier) to do something. By the time you generate code, a message will translate to a function call. In this example, one form is asking another to display itself:
Types of Messages : Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous messages will appear this way.
16
Balking: With this option, the client sends the message to the supplier. If the
supplier is not immediately ready to accept the message, the client abandons the message. On the Sequence diagram, balking messages appear like this.
Timeout: Using this option, the client sends the message to the supplier and
waits a specified amount of time. If the supplier isn't ready to receive the message in that time, the client abandons the message. On the Sequence diagram, timeout messages appear using this arrow.
Asynchronous: With this option, the client sends the message to the supplier.
The client then continues processing, without waiting to see if the message was received or not. On the Sequence diagram, asynchronous messages look like this.
Procedure Call: With this option, the client sends the message to the supplier.
The client then must wait until the entire nested sequence of messages is processed before continuing. On the Sequence diagram, procedure call messages look like this.
17
Return: This option indicates the return from a procedure call. On the Sequence
diagram, return messages look like this.
Objects Identification:
The objects in the sequence diagram are 1. User 2. System 3. Database
18
DIAGRAM: Login:
Notification:
19
Questions and key preparation :
Exercise 5:
1
Write use case realizations for any major three use cases
2. Draw sequence diagrams for above three use case realizations.
20
3. Collaboration Diagram AIM: To represent object interaction for a use case flow of control using
collaboration diagram. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: •
A collaboration diagram is an alternate way to show a scenario. This type of
diagram shows object interactions organized around the objects and their links to each other. •
A collaboration diagram can be created from the sequence diagram by pressing the F5 key in Rational Rose. And vice versa.
•
Why there are two different diagrams for object interaction? Sequence diagrams are useful in the early analysis phases as customers can read and understand this type of diagram. Collaboration diagrams seem to be used more in the design phase of development when you are designing the implementation of the relationships.
Like Sequence diagrams, Collaboration diagrams are used to show the flow through a specific scenario of a use case. While Sequence diagrams are ordered by time, Collaboration diagrams focus more on the relationships between the objects.
21
Basic Collaboration Diagram Symbols and Notations Class roles
Object:
Class
Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don’t list object attributes. Association roles:
Association roles describe how an association will behave given in a particular situation. You can draw association roles using simple lines labeled with stereotypes. Messages:
Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead number messages in order of execution. Sequence numbering can become nested using the Dewey decimal system. For example, nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. A condition for a message is usually placed in square brackets immediately following the sequence number. Use a * after the sequence number to indicate a loop. Objects: The objects in the Collaboration diagram are the same as in the Sequence diagram. Diagrams: Login:
22
Notification:
Exercise 6:
1.
Identify flow of control for any three major use cases.
2.
Draw collaboration diagrams for above use cases.
3.
Observe how a collaboration diagram can be drawn from
existing sequence diagram and vice versa in rational rose
23
5. Activity Diagram AIM: To draw activity diagram of a system to represent workflow of system using
swim lanes and without swim lanes. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
Activity diagrams provide a way to model the workflow of a business process. You can also use activity diagrams to model code-specific information such as a class operation. Activity diagrams are very similar to a flowchart because you can model a workflow from activity to activity. Activity diagrams can model many different types of workflows. Understanding Workflows
Each activity represents the performance of a group of actions in a workflow. Once the activity is complete, the flow of control moves to the next activity or state through a transition. If an outgoing transition is not clearly triggered by an event, then it is triggered by the completion of the contained actions inside the activity. A unique activity diagram feature is a swim lane that defines who or what is responsible for carrying out the activity or state. It is also possible to place objects on activity diagrams. The workflow stops when a transition reaches an end state. You can attach activity diagrams to most model elements in the use case or logical views. Activity diagrams cannot reside within the component view. Activity Diagram Tools You can use the following tools on the activity diagram toolbox to model activity diagrams:
Activities
Decisions
End State
24
Object
Object Flow
Start State
States
Swim lanes
Synchronizations
Transitions
Action states
Action states represent the noninterruptible actions of the objects. You can draw an action state in smart Draw using a rectangle with rounded corners.
Action flow
Action flow arrows illustrate the relationships among action states.
Object flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow fro an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object
25
Initial state
A filled circle followed by an arrow represents the initial action state.
Final state
An arrow pointing to a filled circle nested inside another circle represents the final action state.
Branching
A diamond represents a decision with alternate paths. The outgoing alternates should be
Labeled with a condition or guard expression. You can also label one of the paths “else”. Synchronization A synchronization bar helps illustrate parallel transitions. Synchronization is also
called forking and joining.
Swim lanes
26
Swim lanes group related activities into one column.
Diagram:
27
Exercise:
1. Draw activity diagrams for any two major use cases (with swim lines and another without swim lanes. 2. Draw activity diagram for entire system.
28
6. State Chart Diagram
AIM: To identify different states of an object and draw state chart for its life
cycle .A State chart diagram shows the life cycle of a single object, from the time that it is created until it is destroyed. These diagrams are a good way to model the dynamic behavior of a class. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
A state chart diagram shows the behavior of classes in response to external stimuli. This diagram models the dynamic flow of control from state to state within a system.
States: States representing situations during the life of an object. You can easily
illustrate a state in Smart Draw by using a rectangle with rounded corners.
Transition:
A solid arrow represents the path between different states of an object. Label the transition with the event that triggered it and the action that results from it.
29
Initial State:
A filled circle followed by an arrow represents the object’s initial state.
Final State:
An arrow pointing to a filled circle nested inside another circle represents the object’s final state.
Synchronization and splitting of control
A short heavy bar with two transitions entering it represents a synchronization of control. A short heavy bar with two transitions leaving it represents a splitting of control that creates multiple states. Sequential States:
The sequential states in our state diagram 1 are idle, login, send problem, receive prescription, and pay fee and log out. The sequential states in state diagram 2 are idle, login, read problem, send problem, receive prescription, send prescription, take fee, pay salary, logout. The sequential states of diagram 3 are idle, login, read problem, send prescription, take salary.
30
Diagrams: Student:
Conveyor:
idle
questions prep
enter id
setup test centers
manage database
appoint faculty
send results
invigialtion
enter password
31
Faculty:
idle
questions prep
invigialtion
enter id
enter password
Exercise:
1. Identify all possible states for any three objects of your system 2. Draw state chart for each of above objects to represent their life cycles.
32
7. Component Diagram
AIM: To identify all software components and associations among them and to draw
Component diagram SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
Component diagrams provide a physical view of the current model. A component diagram shows the organizations and dependencies among software components, including source code components, binary code components, and executable components. These diagrams also show the externally-visible behavior of the components by displaying the interfaces of the components. Calling dependencies among components are shown as dependency relationships between components and interfaces on other components. Note that the interfaces actually belong to the logical view, but they can occur both in class diagrams and in component diagrams. Component diagrams contain: ·
Component packages
·
Components
·
Interfaces
·
Dependency relationships
You can create one or more component diagrams to depict the component packages and components at the top level of the component view, or to depict the contents of each component package. Such component diagrams belong to the component package that they depict. A Component Package Specification enables you to display and modify the properties of a component package. Similarly, a Component Specification and a Class Specification enables you to display and modify the properties of a component and an interface, respectively. The information in these specifications is presented textually.
33
Some of this information can also be displayed inside the icons representing component packages and components in component diagrams, and interfaces in class diagrams. You can change properties of, or relationships among, component packages, components, and interfaces by editing the specification or modifying the icon on the diagram. The affected diagrams or specifications are automatically updated. Basic Component diagram symbols and Notations
Component
A component is a physical building block of the system. It is represented as a rectangle with tabs.
Interface
An interface describes a group of operations used or created by components.
Dependencies
34
Draw dependencies among components using dashed arrows. Diagram:
Exercise:
1. Identify all required components of your system and draw a detail Component diagram
35
8. Deployment Diagram AIM: To identify all runtime components and implementation architecture of system
and to draw Deployment diagram SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
A deployment diagram shows processors, devices, and connections. Each model contains a single deployment diagram which shows the connections between its processors and devices, and the allocation of its processes to processors. Processor Specifications, Device Specifications, and Connection Specifications enable you to display and modify the respective properties. The information in a specification is presented textually; some of this information can also be displayed inside the icons. You can change properties or relationships by editing the specification or modifying the icon on the diagram. The deployment diagram specifications are automatically updated. Basic Deployment diagram symbols and Notations
Node
A node is a physical resource that executes code components.
36
Association
Association refers to a physical connection between nodes, such as Ethernet.
Components and Nodes
Place components inside the node that deploys them.
37
Diagram:
db server d a t a b a se . d d l
system
user
service manager
sudent.exe faculty.exe
a d m i n o f f i ce r .e x e conveynor.exe
Exercise
1. Identify all implementation nodes of your system and draw deployment diagram for your system
38
9. Selection of a Case Study – Problem Statement AIM: Select the problem to be solved as case study by each team and preparation of
Technical problem statement for the same .Example: ONLINE EAMCET EXAM. PROCEDURE:
The following are the users which can access the database .They are emcee conveyor, student and faculty. The emcee conveyor issues the notification for the particular year. After receiving the applications from the students, he issues hall tickets online .He manages the database and the entire system. He appoints the faculty and also set up regional test centers with required infrastructure .A regional centre will have few computers and a local server which will manage the tests. This server will manage the question bank and as well as results of the test taker. The faculty has access to the question bank server and they can only add more questions to it. Some of the faculty is appointed as invigilators for the test. A student can take only one time in a year at the test center and the score is valid for two years. Students have to register online for the test with a valid identity proof. The payment can be made through credit cards or through demand draft. The results are sending to the test takers through postal mail. Admission offices of all registered institutions have access to the results through which they can verify the score.
Exercise 1: •
Select a system and write the problem statement for the selected system
39
10. Software Requirement Specification
AIM: Preparation of SRS document to understand the system characteristics in detail. PROCEDURE: •
Standard SRS should include the following 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions 1.4 References 1.5 Overview
2. Overall Description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and Dependencies
3. Specific Requirements 3.1 Functional requirements 3.2 Non functional requirements 3.3 Performance requirements 3.4 External interfaces 3.5 Software system attributes
40
1. INTRODUCTION
1.1
Purpose
The purpose of the online emcee exam is to make eamcet online and make conducting and evaluating the result easy. 1.2
Scope
The main users of the system are conveynor, student, and faculty and admission officer. 1.3
Definitions, acronyms and abbreviations
Reg-regional Admn-admission Ques prep-question preparation 1.4
Overview
General description deals with project perspective, project function, user characteristics and general constraints. Specific requirements deal with external interface requirements, performance requirements and design constraints. 2. GENERAL DESCRIPTION
2.1
Product perspective
The online eamcet exam is used when student wants to join engineering. 2.2
Product function
The main function of online eamcet exam is to accept request for the students to write exam and get the results immediately. 2.3
User characteristics
Main users are conveynor,student and faculty Convey nor:-he should have the knowledge of managing a nd conducting the exam. Student:-he should have the knowledge of applying and writing the exam. Faculty:-he should have the knowledge of preparing questions and conducting exam. 41
2.4
General constraints
It works only on windows. 3. SPECIFIC REQUIREMENTS
3.1
External Interface requirements
3.1.1
User Interfaces HTML
3.1.2
Hardware Interfaces Keyboard, Mouse
3.1.3
Software Interfaces Rational Rose, Windows
3.2
FUNCTIONAL REQUIREMENTS •
3.2.1 Login:-It allows the users to use the services. It takes in
login id and password and returns to the next page . •
3.2.2 Notification:-conveyor notifies the data for applying hall
tickets and date of exam. •
3.2.3 issue hall ticket:-after receiving applications ,conveynor
issues hall tickets for eligible students online. •
3.2.4 appoint faculty:-conveynor appoints the faculty for
conducting test. •
3.2.5 Manage database:-conveynor manages the database which
consists of question bank and results. •
3.2.6 Setup regional test centers:-conveyor setup regional test
centers with infrastructures. •
3.2.7 Sendresults:-conveynor sends results to the test ta kers
through postal mail. •
3.2.8 Conduct counseling:-conveyor conducts counseling for
the test takers to join in institutions. •
3.2.9 Logout:-the user logout after their work is completed.
•
3.3.1 Register online:-the students register online for the test
with a valid identity proof. •
3.3.2payfees:-the students pay fees through credit card or
demand draft. •
3.3.3 Take test: - the students write the test. 42
•
3.3.4 Questions preparation:-the faculty prepares the questions
bank. •
3.3.5 Invigilation:-the faculty conducts the test.
•
3.3.6 Verify results:-admissions of registered institutions verify
the results. 3.3
NON FUNCTIONAL REQUIREMENTS
The system is dependable, reliable and interoperable. Static requirements: A limited number of customers can only login to the hotel based on the no of rooms present in that hotel. Dynamic requirements: Query processing time is 10 ms. 3.4
DESIGN CONSTRAINTS
The login of conveyor and faculty has to provide their password.
Exercise 2:
Write SRS for the case or system chosen by you.
43
Design Based Experiments
1. Class Diagram AIM: To design Road Transport Authority System by using class diagram. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented systems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Graphically, a class diagram is a collection of vertices and arcs. A class diagram is a picture for describing generic descriptions of possible systems. Class diagrams and collaboration diagrams are alternate representations of object models. Class diagrams contain classes and object diagrams contain objects, but it is possible to affix classes and objects when dealing with various kinds of metadata, so the separation is not rigid. Class diagrams are more prevalent than object diagrams. Normally you will build class diagrams plus occasional object diagrams illustrating complicated data structures-or message-passing structures. Class diagrams contain icons representing classes, interfaces, and their relationships. You can create one or more class diagrams to depict the classes at the top level of the current model; such class diagrams are themselves contained by the top level of the current model. You can also create one or more class diagrams to depict classes contained by each package in your model; such class diagrams are themselves contained by the package enclosing the classes they depict; the icons representing logical packages and classes in class diagrams We can change properties or relationships by editing the specification or
44
modifying the icon on the diagram. The associated diagrams or specifications are automatically updated.
Class diagrams are the backbone of almost every object oriented method including UML. Class diagrams describe the static structure of a system. Contents: Class Diagrams commonly contain the following things: Classes Interfaces Collaborations Dependency, generalization and association relationships 2. Classes & Interfaces: Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically a class is rendered as a rectangle, usually including its name, attributes and operations, as shown below.
Window Origin Size Open () Close () Display () Interface:
An interface is a collection of operations that specify a service of a class or component. An interface describes the externally visible behavior of that element. Graphically the interface is rendered as a circle together with its name.
45
ISpelling
The various classes in our class diagram are:
RTA
Employee
Operator
Administrator
Accountant
Officer
Helpdesk
Applicant
Report
46
Diagram:
RTA Region Code Phno A dd Provide Facilities()
Employee name id salary()
operator
administrator
officer
accountant
name id
name id
name id
name id
a c c e p t re g ( ) allot pid()
record maintenance() r e c o r d c l a s s i fi c a t i o n ()
accept payments() generate bills() prepare report()
tes t drive prep() invigilation() issue licence()
applicant helpdesk
name p id
name id
gets registered() t a k e s t e s t () b i ll p a y m e n t s ( )
r e s p o n d t o q u e r ie s ( )
report no daily repo rt() m o n t h l y r e p o r t ()
test certificates
47
verification
2. Sequence Diagram
AIM: To design Road transport authority system by using sequence diagram. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. This type of diagram is best used during early analysis phases in design because they are simple and easy to comprehend. Sequence diagrams are normally associated with use cases. Sequence diagrams are closely related to collaboration diagrams and both are alternate representations of an interaction. There are two main differences between sequence and collaboration diagrams: sequence diagrams show time-based object interaction while collaboration diagrams show how objects associate with each other. A sequence diagram has two dimensions: typically, vertical placement represents time and horizontal placement represents different objects. The following tools located on the sequence diagram toolbox enable you to model sequence diagrams:
Object
Message Icons
Focus of Control
Message to Self
Note
Note Anchor
48
A sequence diagram consists of the following sequence diagram behavioral elements.
Element and its description
Symbol
Object: The primary element involved in a sequence diagram is an object—an instance of a class. A Sequence diagram consists of sequence of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the “.” Is the object name and to its right is the class name. Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a sequence diagram, you can represent simple messages, Special messages to create or destroy objects, and message responses.
The steps involved in creating a Sequence are:
Identify objects.
Identify actors.
Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term that represents some concrete, real-world thing. Examples of objects are: airplane, a flight, a passenger, a piece of luggage, or a ticket. Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of events. Another good place to look is in the scenario documents. A scenario is a specific instance of a flow of events.
49
Lifeline
It specifies the existence of the Object. Each object has a lifeline , drawn as a vertical dashed line below the object. The lifeline begins when the object is instantiated and ends when the object is destroyed. Focus of Control
In a Sequence diagram, you have the option of showing the focus of control, which lets you know which object has control at a particular point in time. A small vertical rectangle represents the focus of control. Messages
A message is a communication between objects in which one object (the client) asks another object (the supplier) to do something. By the time you generate code, a message will translate to a function call. In this example, one form is asking another to display itself:
Types of Messages : Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous messages will appear this way.
50
Balking: With this option, the client sends the message to the supplier. If the
supplier is not immediately ready to accept the message, the client abandons the message. On the Sequence diagram, balking messages appear like this.
Timeout: Using this option, the client sends the message to the supplier and
waits a specified amount of time. If the supplier isn't ready to receive the message in that time, the client abandons the message. On the Sequence diagram, timeout messages appear using this arrow.
Asynchronous: With this option, the client sends the message to the supplier.
The client then continues processing, without waiting to see if the message was received or not. On the Sequence diagram, asynchronous messages look like this.
Procedure Call: With this option, the client sends the message to the supplier.
The client then must wait until the entire nested sequence of messages is processed before continuing. On the Sequence diagram, procedure call messages look like this.
51
Return: This option indicates the return from a procedure call. On the Sequence
diagram, return messages look like this.
Objects Identification:
The objects in the sequence diagram are 4. User 5. System 6. Database
52
1: Register
:user
:system
:database
1: send request with details
2: enter in database 3: send confortmation 4: send PID and date
2: Payment & Verification :user
:accountant
:database
1: submit certificates 2: validate 3: send conformation
4: makes payment 5: enter in database 6: send conformation 7: send report
53
3: Test :user
:system
:question bank
1: send test details
:database
2: get questions 3: send questions 4: start test 5: submit 6: validate 7: store score in dB 8: send conformation
9: send score
4: Issue of License
:user
:officer
:database
1: takes track test 2: validate 3: enter in dB 4: send conformation 5: issue license
54
3. Collaboration Diagram AIM: To Design Road transport authority system by using collaboration diagram. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: •
A collaboration diagram is an alternate way to show a scenario. This type of
diagram shows object interactions organized around the objects and their links to each other. •
A collaboration diagram can be created from the sequence diagram by pressing the F5 key in Rational Rose. And vice versa.
•
Why there are two different diagrams for object interaction? Sequence diagrams are useful in the early analysis phases as customers can read and understand this type of diagram. Collaboration diagrams seem to be used more in the design phase of development when you are designing the implementation of the relationships.
Like Sequence diagrams, Collaboration diagrams are used to show the flow through a specific scenario of a use case. While Sequence diagrams are ordered by time, Collaboration diagrams focus more on the relationships between the objects. Basic Collaboration Diagram Symbols and Notations Class roles
Object:
Class
Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don’t list object attributes. Association roles:
Association roles describe how an association will behave given in a particular situation. You can draw association roles using simple lines labeled with stereotypes.
55
Messages:
Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead number messages in order of execution. Sequence numbering can become nested using the Dewey decimal system. For example, nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. A condition for a message is usually placed in square brackets immediately following the sequence number. Use a * after the sequence number to indicate a loop. Objects: The objects in the Collaboration diagram are the same as in the Sequence diagram. Diagrams:
1: Register
4: send PID and date :user
1: send request with details :system 3: send confortmation
2: enter in database :database
56
2: Payment and Verification 2: validate
:user
1: submit certificates 4: makes payment :accountant 3: send conformation 7: send report
6: send conformation 5: enter in database
:database
3: Test 6: validate
1: send test details 5: submit
:system
:user 4: start test 9: send score 7: store score in dB
3: send questions
8: send conformation 2: get questions
:databas e
:question bank
57
4: Issue of License 2: validate
:user
1: takes track test :officer 5: issue license 4: send conformation
3: enter in dB
:database
58
4. State Chart Diagram AIM: To Design road transport authority system by using state chart diagram. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
A state chart diagram shows the behavior of classes in response to external stimuli. This diagram models the dynamic flow of control from state to state within a system.
States: States representing situations during the life of an object. You can easily
illustrate a state in SmartDraw by using a rectangle with rounded corners.
Transition:
A solid arrow represents the path between different states of an object. Label the transition with the event that triggered it and the action that results from it.
Initial State:
A filled circle followed by an arrow represents the object’s initial state.
59
Final State:
An arrow pointing to a filled circle nested inside another circle represents the object’s final state.
Synchronization and splitting of control
A short heavy bar with two transitions entering it represents a synchronization of control. A short heavy bar with two transitions leaving it represents a splitting of control that creates multiple states. Sequential States:
The sequential states in our state diagram 1 are idle, login, send problem, receive prescription, and pay fee and log out. The sequential states in state diagram 2 are idle, login, read problem, send problem, receive prescription, send prescription, take fee, pay salary, logout. The sequential states of diagram 3 are idle, login, read problem, send prescription, take salary.
60
Diagram:
Online test fai led
Registration
Verification & payment
Active Online Test
Evaluation
Online test passed
Completed
61
5. Use case diagrams AIM: To identify actors, use cases and relationships for representing functional
Requirement of system using Use case diagrams. SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE: Actor:
Actors represent system users. They help delimit the system and give a clearer picture of what the system should do. It is important to note that an actor interacts with, but has no control over the use cases. An actor is someone or something that: ·
Interacts with or uses the system
·
Provides input to and receives information from the system
·
Is external to the system and has no control over the use cases
Actors are discovered by examining: ·
Who directly uses the system?
·
Who is responsible for maintaining the system?
·
External hardware used by the system
·
Other systems that need to interact with the system
The needs of the actor are used to develop use cases. This insures that the system will be that the user expected.
62
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case diagram. Naming
The name of the actor is displayed below the icon. Additional information about the actor can be viewed in the Use-Case Specification which is identical to a Class Specification with the addition of the Stereotype field set to actor. Use cases: A use case is a high-level piece of functionality that the system will provide
In its simplest form, a use case can be described as a specific way of using the system from a user’s (actor’s) perspective. A more detailed description might characterize a use case as:
·
A pattern of behavior the system exhibits
·
A sequence of related transactions performed by an actor and the system
·
Delivering something of value to the actor
Use cases provide a means to: ·
capture system requirements
·
communicate with the end users and domain experts
·
test the system
Use cases are best discovered by examining the actors and defining what the actor will be able to do with the system. Since all the needs of a system typically cannot be covered in one use case, it is usual to have a collection of use cases. Together this use case collection specifies all the ways of using the system. By looking at the use cases, the customer can see what functionality will be provided, and can agree to the system scope before the project goes any further
63
Graphical Depiction
The basic shape of a use case is an ellipse: Naming
A use case may have a name, although it is typically not a simple name. It is often written as an informal text description of the actors and the sequences of events between objects. Use case names often start with a verb. For example, names of possible use cases for an ATM machine might include Dispense Cash or Transfer Funds. The name of the use case is displayed below the icon. Additional information about a use case can be viewed in the Use-Case specification.
Relationships There are four types of relationships 1. Association 2. Includes relationship 3. Extends relationship 4. Generalization relationship. You can draw an Association relationship from a use case to an actor. You can draw a Generalize relationship between two use cases and /or two actors You can draw a Dependency relationship between two use cases.
64
USECASE DIAGRAM:
send a request for license
User Takes track test
validate the test
Officer issue license
Receive the details of user
Accountant
Update the database
Send report to user and officer
65
6. Deployment Diagram AIM: To identify all runtime components and implementation architecture of system
and to draw Deployment diagram SOFTWARE REQUIREMENTS: •
Operating system: Windows XP
•
Software
: Rational Rose
HARDWARE REQUIREMENTS: •
PROCESSOR : Pentium IV ,2.6 GHz
•
Memory
•
Hard disk capacity: 80 GB
:256 MB
PROCEDURE:
A deployment diagram shows processors, devices, and connections. Each model contains a single deployment diagram which shows the connections between its processors and devices, and the allocation of its processes to processors. Processor Specifications, Device Specifications, and Connection Specifications enable you to display and modify the respective properties. The information in a specification is presented textually; some of this information can also be displayed inside the icons. You can change properties or relationships by editing the specification or modifying the icon on the diagram. The deployment diagram specifications are automatically updated. Basic Deployment diagram symbols and Notations
Node
A node is a physical resource that executes code components.
66
