Professional Documents
Culture Documents
Umldp Lab Manual
Umldp Lab Manual
UML makes a clear conceptual distinction between models, views and diagrams. A Model is an
element that contains information for a software model. A View is a visual expression of the
information contained in a model, and a Diagram is a collection of view elements that represent
the user’s specific design thoughts.
Building Blocks of UML : Things ,Relationships and diagrams.
Things in UML :
Structural things:
Classes
Interfaces
Collaborations
Use Cases
Active Classes
Components
Nodes Classes
Behavioral things:
Interactions
State machines
Grouping things
Packages
Annotational things
Notes
Diagrams in UML :
Class Diagram
Object Diagram
Usecase Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployement Diagram
Class:
A class is the descriptor for a set of objects with similar structure, behavior, and
relationships.It is represented by a rectangle.
Interface:
[Type text]
GVP College of Engineering for Women
Relations:
Association
Dependency
Generalization
Realization
In addition to this there are
Directed Association
Aggregation and
Composition
Association:
An association is a structural relationship that specifies the relation between two objects
when they are at the same level (peer level systems).
An Association can specify the relationship, role of the class and Multiplicty.
An Association used in class diagram, Component diagram, deployment diagram, usecase
diagrams.
The multiplicity can be represented as 1-1..*,*,0…1.
It is represented as follows:
Directed Association:
Links a semantic association between two classes in the UML diagram.
Directed association is used in class diagram, Component diagram, deployment diagram,
usecase diagrams.
Symbol:
GVP College of Engineering for Women
Aggregation:
Links a semantic association between two classes in the UML diagram.
Aggregation is used in class diagram.
Symbol:
Composition:
Links a semantic association between two classes in the UML diagram.
Composition is used in class diagram.
Symbol:
Generalization:
Generalization is a specification relationship in which objects of the specialized element
(the child ) are substitutable for objects of the generalization element (the parent).It is used in
class diagram.
Symbol:
Dependency:
A dependency is a semantic relationship in which if there is any change occurred in one
object that may effect other object.
Dependency is used in class diagram, Component diagram, deployment diagram,
usecase diagrams.
Symbol:
------------------------------------------
GVP College of Engineering for Women
Realization:
Realization is a Specified tool that can be represented by providing a relationship with
classifier.
Dependency is used in class diagram, Component diagram, deployment diagram, usecase
diagrams.
Symbol:
----------------------------------------------
Class diagrams:
A class diagram is that which represents a set of classes,interfaces,and collobrations
and their relationships,graphically a class diagram is a collection of vertices and arcs.
It consists of three compartments.
Name
Attributes
operations
Uses:
A class diagram is used to model the static design view of a system.
Object diagrams:
An object diagram shares the same common properties of all other diagrams.
;Name
Attributes
operations
Uses:
An object diagram is used to model the static design view of a system.
UseCase Diagrams:
An usecase diagram shares the common properties as all diagrams.It distinguishes in the
contents of use cases, actors, dependency, generalization relationships.
Actor
Uses:
An Usecase diagram is used to model the static design view of a system.
GVP College of Engineering for Women
Interaction Diagrams:
An Interaction diagram shares the same common properties as all other diagrams. It
differs in its contents
Objects
Links
Messages
It includes two diagrams – Sequence and Collaboration
Sequence Diagrams:
A sequence diagram emphasizes the time ordering of messages.Sequence diagrams have
two features that distinguish them from collaboration diagrams.
(i)Object life time
(ii)The focus of control
Collaboration Diagrams:
A collaboration diagram emphasizes the organization of the objects that participate in an
interaction
Collaboration diagrams have two features that distinguish them from sequence diagrams.
(i)Path
(ii) The Sequence number
Object:
It is an instance of a class.
Stimulus:
A Stimulus is a communication between two Instances that conveys information with the
expectation that action will ensue. A Stimulus will cause an Operation to be invoked, raise a
Signal, or cause an Instance to be created or destroyed.
Symbol:
Send:
Return: ------------------------------------------
GVP College of Engineering for Women
Create:
<<create>>
Destroy:
<<destroy>>
Uses:
Interaction diagrams are used to model the dynamic aspects of a system. It is obtained in
two ways:
(i) To model flows of control by time ordering.
(ii) To model flows of control by organization.
Symbol:
State Name
SubmachineState:
A submachine state is a syntactical convenience that facilitates reuse and modularity. It
is a shorthand that implies a macro-like expansion by another state machine and is semantically
equivalent to a composite state.
Symbol:
GVP College of Engineering for Women
Initial State:
An initial is a kind of pseudostate that represents the starting point in a region of a state
machine. It has a single outgoing transition to the default state of the enclosing region, and has
no incoming transitions. There can be one (and only one) initial state in any given region of a
state machine. It is not itself a state but acts as a marker.
Symbol:
Final State:
A final state represents the last or "final" state of the enclosing composite state. There
may be more than one final state at any level signifying that the composite state can end in
different ways or conditions. When a final state is reached and there are no other enclosing
states it means that the entire state machine has completed its transitions and no more transitions
can occur.
Symbol:
JunctionPoint:
Junction Point chains together transitions into a single run-to-completion path. May have
multiple input and/or output transitions. Each complete path involving a junction is logically
independent and only one such path fires at one time. May be used to construct branches and
merges.
Symbol:
Transition:
A transition is a directed relationship between a source state vertex and a target state
vertex. It may be part of a compound transition, which takes the state machine from one state
configuration to another, representing the complete response of the state machine to a particular
event instance.
Symbol:
Activity Diagram:
It represents the different activities in the system.
ActionState:
GVP College of Engineering for Women
An action state represents the execution of an atomic action, typically the invocation of
an operation. An action state is a simple state with an entry action whose only exit transition is
triggered by the implicit event of completing the execution of the entry action. The state
therefore corresponds to the execution of the entry action itself and the outgoing transition is
activated as soon as the action has completed its execution.
Symbol:
SubactivityState:
A subactivity state represents the execution of a non-atomic sequence of steps that has
some duration; that is, internally it consists of a set of actions and possibly waiting for events.
That is, a subactivity state is a hierarchical action, where an associated subactivity graph is
executed.
Symbol:
Sub Activity
Name
InitalState:
An initial is a kind of pseudostate that represents the starting point in a region of a state
machine. It has a single outgoing transition to the default state of the enclosing region, and has
no incoming transitions. There can be one (and only one) initial state in any given region of a
state machine. It is not itself a state but acts as a marker.
Symbol:
FinalState:
A final state represents the last or "final" state of the enclosing composite state. There
may be more than one final state at any level signifying that the composite state can end in
different ways or conditions. When a final state is reached and there areno other enclosing states
it means that the entire state machine has completed its transitions and no more transitions can
occur.
Symbol:
Decision:
A state diagram (and by derivation an activity diagram) expresses a decision when guard
conditions are used to indicate different possible transitions that depend on Boolean conditions
of the owning object.
Symbol:
GVP College of Engineering for Women
Component Daigrams:
Package:
A package is a grouping of model elements. Packages themselves may be nested within
other packages. A package may contain subordinate packages as well as other kinds of model
elements. All kinds of UML model elements can be organized into packages.
Symbol:
Interface:
An interface is a specifier for the externally-visible operations of a class, component, or
other classifier (including subsystems) without specification of internal structure.
Symbol:
Component:
A component represents a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces.
Symbol:
Artifact:
An Artifact represents a physical piece of information that is used or produced by a
software development process. Examples of Artifacts include models, source files, scripts, and
binary executable files. An Artifact may constitute the implementation of a deployable
component.
Symbol: <<artifact>>
Deployment Diagrams:
Package:
A package is a grouping of model elements. Packages themselves may be nested within
other packages. A package may contain subordinate packages as well as other kinds of model
elements. All kinds of UML model elements can be organized into packages.
Symbol:
Node:
GVP College of Engineering for Women
Node Name
NodeInstance:
A node instance is an instance of a node. A collection of component instances may
reside on the node instance.
Symbol:
Node Name
Artifact:
An Artifact represents a physical piece of information that is used or produced by a
software development process. Examples of Artifacts include models, source files, scripts, and
binary executable files. An Artifact may constitute the implementation of a deployable
component.
Symbol:
<<artifact>>
GVP College of Engineering for Women
WEEK – 1
Step-2: Select and click on “Install IBM Rational Rose Enterprise Edition”
GVP College of Engineering for Women
Step-14:
Import
location of
source folder
Step-18: IBM Rational Rose setup has been completed .Click on “Finish”
GVP College of Engineering for Women
Introduction:
Menubar: The menubar consists of several menus like the file menu, edit menu, view menu
etc. All these menus contain several options.
Toolbar: The toolbar contains the most frequently used actions like New, Open, Save etc…
Status bar: The status bar at the bottom displays status messages.
Browser Window: The browser window displays the views: Use Case View, Logical View,
Component View and Deployment View. Each of these views contains the diagrams.
GVP College of Engineering for Women
Diagram Toolbar: The diagram toolbar displays the symbols of the respective type of diagram.
Diagram Window: The diagram window is the place where the user draws the diagrams using
the symbols from the diagram toolbar.
Log Window: This window is used to display error messages, warnings and information
messages.
Documentation Window: This window is used to display the documentation related to the
symbols and other aspects.
• Rational Rose’s main advantage is its flexibility. This flexibility comes in part from its support
for many object-oriented languages including Java, MFC C++, Visual Basic, as well as Oracle
8i databases.
• Component reuse and a more efficient utilization of software development resources are
additional advantages.
• Supports both round-trip engineering and reverse engineering.
• Round-trip engineering (RTE) is a functionality of software development tool that
synchronizes two or more related software artifacts, such as, source code, models, configuration
files, and other documents.
• Rose a proprietary s/w so not completely integrated with the Microsoft IDE and other
important development tools.
Creating actors
1. Right-click on the Use Case View package in the browser to make the shortcut menu visible.
2. Select the New:Actor menu option. A new actor called New Class is placed in the browser.
3. With the actor called New Class selected, enter the desired name of the actor.
Documenting Actors
1. If the documentation window is not visible, open the documentation window by selecting the
Documentation menu choice from the View menu.
2. Click to select the Actor in the browser.
3. Position the cursor in the documentation window and enter the documentation.
1. Right-click on the Use Case View in the browser to make the shortcut menu visible.
2. Select the New:Use Case menu option. A new unnamed use case is placed in the browser.
3. With the use case selected, enter the desired name of the use case.
1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the specification menu option.
3. Select the Files tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert File menu option.
6. Browse to the appropriate directory and select the desired file.
7. Click the Open button.
8. Click the OK button to close the specification.
1. Double-click on the Main diagram in the use case view in the browser to open the diagram.
2. Click to select an actor in the browser and drag the actor onto the diagram.
3. Repeat step 2 for each additional actor needed in the diagram.
GVP College of Engineering for Women
4. Click to select a use case in the browser and drag the use case onto the diagram.
5. Repeat step 4 for each additional use case needed in the diagram.
Note: Actors and use cases may also be created directly on a use case diagram by using the
toolbar.
1. Click to select the association icon or the Unidirectional Association icon from the toolbar.
Note: if the association icon is not present on the toolbar, it may be added by right clicking on
the toolbar, selecting the Customize menu choice from the shortcut menu, and adding the icon to
the toolbar.
2. Click on an actor initiating a communication and drag the association line to the desired use
case.
To add the Communicates stereotype (optional):
1. ouble-click on the association line to make the Specification visible.
2. If this is the first time the stereotype is being used, enter Communicates in the Stereotype
field. If a Communicates stereotype has already been created, click the arrow in the Stereotype
field to make the drop-down menu visible and Select Communicates.
3. Click the OK button to close the specification.
4. Right-click on the association line to make the shortcut menu visible.
5. Select the Show Stereotype menu choice.
6. Repeat the preceding steps for each additional association relationship.
GVP College of Engineering for Women
1. Right-click on the Use Case View in the browser to make the shortcut menu visible.
2. Select the New:Use Case Diagram menu option.
3. While the use case diagram is selected, enter the name of the use case diagram.
4. Open the diagram and add actors, use cases, and interactions to the diagram as needed.
2. Class Diagram
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu choice.
3. Select the General tab.
4. Enter the name of the stereotype.
5. Click the OK button to close the Specification.
GVP College of Engineering for Women
Documenting Classes
Rose automatically creates the Main class diagram in the Logical View of the model.
To add packages to the Main class diagram:
1. Double-click on the Main diagram in the browser to open it.
2. Click to select the package in the browser.
3. Drag the package onto the diagram.
4. Repeat the preceding steps for each package that is to be added to the diagram.
GVP College of Engineering for Women
1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the New:Class Diagram menu choice.
3. While the diagram is still selected, enter the name of the class diagram.
4. Double-click on the diagram in the browser to open the diagram.
5. Click to select a class in the Logical view of the browser and drag the class onto the diagram.
6. Repeat step 5 for each additional class that is to be placed onto the diagram.
1. Right-click on the class in a class diagram to make the shortcut menu visible.
2. Select the Show Stereotype menu choice.
Naming Relationships
1. Right-click on the relationship line near the class that it modifies to make the shortcut menu
visible.
2. Select the Role Name menu choice.
3. Enter the name of the role.
Creating Multiplicity
Documenting Operations
1. Click the + next to the class in the browser to expand the class.
2. Click to select the operation.
3. Position the cursor
Creating Attributes
1. Right-click to select the class in the browser and make the pop-up menu visible.
2. Select the New:Attribute menu choice. This will create an attribute called Name in the
browser.
GVP College of Engineering for Women
Documenting Attributes
1. Click the + next to the class in the browser to expand the class
2. Click to select the attribute.
3. Position the cursor in the documentation window and enter the documentation for the
attribute.
Creating a Class diagram to show the Attributes and Operations for a Package
1. Right-click to select the package in the browser and make the shortcut menu visible.
2. Select the New:Class Diagram menu choice. A class diagram called NewDiagram will be
added to the browser.
3. With the new diagram selected, enter the name of the diagram.
Filtering Relationships
1. Right-click to select the class on an opened class diagram and make the shortcut menu visible.
2. Select the Edit compartment menu choice.
3. Click to select the attributes and operations to be displayed.
4. Click the >>>> button.
5. Click the OK button to close the Edit Compartment window.
1. Right-click on the class in the class in a diagram to make the shortcut menu visible.
2. Select the Show All Attributes menu choice to display all the attributes for the class.
3. Repeat step 1 and select the Show All Operations menu choice to display all the operations
for the class.
GVP College of Engineering for Women
Note: to always display the attributes and operations for a class, you can set the Show All
Attributes and Show All Operations selections using the Tools:Options menu.
Creating Inheritance
1. Open the class diagram that will display the inheritance hierarchy.
2. Click to select the class icon from the toolbar and click on the open class diagram to draw the
class.
3. With the class still selected, enter the name of the class.
Note: The class could also be created in the browser and added to the opened class diagram.
4. Click to select the Generalization icon on the toolbar.
5. Click on a subclass and drag the generalization line to the superclass.
6. Repeat step 5 for each additional subclass.
1. Open the class diagram that will display the inheritance hierarchy.
2. Click to select the class icon from the toolbar and click on the opened class diagram to draw
the class.
3. With the class still selected, enter the name of the class.
Note: The class could also be created in the browser and added to the opened class diagram.
4. Click to select the Generalization icon on the toolbar.
5. Click on one subclass and drag the generalization line to the superclass.
6. For each subclass that is part of the inheritance tree, select the Generalization icon from the
toolbar, click on the subclass, and drag the generalization line to the inheritance triangle.
Note: an inheritance tree may be created from two separate generalization arrows by selecting
one arrow and dragging it onto the other arrow.
1. Click the + sign next to one subclass in the browser to expand the class.
2. Select the attribute or operation to be relocated.
3. Drag the attribute or operation to the superclass.
4. Delete the attribute or operation from all other subclasses.
5. Repeat steps 2 through 4 for each additional attribute or operation to be relocated.
1. Click to select the Parameterized class icon from the toolbar. You may have to add this icon
to the toolbar using the Customize option.
2. Click on a class diagram to place the parameterized class.
3. While the parameterized class is still selected, enter its name.
GVP College of Engineering for Women
14. Draw a dependency relationship between the instantiated class and the parameterized class.
15. Add relationships to the instantiated class as needed.
1. Right-click to select in the browser or on a class diagram and make the shortcut menu visible.
2. Select the Specification menu choice.
3. Select the Attributes tab.
4. Attributes will have a data type set to type and an initial value set to initval. Click to select the
type or initval and place the field in edit mode.
5. Enter the desired data type or initial value.
1. Right-click to select a class in the browser or on a class diagram and make the shortcut menu
visible.
2. Select the Specification menu choice.
3. Select the Operations tab.
4. Double-click on an operation to make the Operation Specification visible.
5. Enter the return class on the General tab.
6. Select the detail tab.
7. Right-click on the Arguments field to make the shortcut menu visible.
8. Select the Insert menu choice. This will add an argument. Enter the name, data type, and
default value for the argument.
9. Click the Ok button to close the Operation Specification.
10. Click the Ok button to close the Class Specification.
GVP College of Engineering for Women
Note: Attribute and Operation detail may also be set on a class diagram by selecting the
displayed item and using the following format: attribute: type = initial value
opration (argname: argtype = default): return class
1. Click the + next to the class in the browser to expand the class.
2. Right-click on the operation to make the shortcut menu visible.
3. Select the Specification menu choice.
4. Select the cg tab.
5. Click to select the value for the property Operation Kind. This will place the value in edit
mode.
6. Select virtual to make the operation virtual. Select abstract to make the operation pure virtual.
7. Click the OK button to close the Specification.
3. Interaction Diagrams
1. Right-click to select the use case in the browser and make the shortcut menu visible.
2. Select the New:Sequence Diagram menu choice. An unnamed sequence diagram is added to
the browser.
3. With the new sequence diagram selected, enter the name of the sequence diagram.
1. Assign the objects to classes if that has not been done previously.
2. Right-click on the message arrow to make the shortcut menu visible.
3. Select the <new operation> menu choice. This will open the Operation Specification.
4. Enter the name of the operation in the Operation Specification.
5. Click the OK button to close the Operation Specification.
6. Right-click on the message arrow to make the shortcut menu visible.
7. Select the operation from the list of operations for the class.
Note: If the desired operation already exists for the class, you do not have to recreate the
operation; simply select the operation from the list of operations for the class.
GVP College of Engineering for Women
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the State Diagram menu choice. This will automatically create and open the diagram.
3. To open the diagram at another time, click the + to expand the class in the browser, and
double-click on its state transition diagram in the browser.
Creating States
5. Architectural Diagrams
1. Right-click to select the Component View package on the browser and make the shortcut
menu visible.
2. Select the New:Package menu choice. This will add an item called NewPackage to the
browser.
3. With the NewPackage still selected, enter the name of the package.
1. Double-click on the Main Diagram under the Component View package on the browser to
open the diagram.
2. Click to select a package and drag the package onto the diagram.
3. Repeat step 2 for each additional package.
4. Dependency relationships are added by selecting the dependency icon from the toolbar,
clicking on the package representing the client, and dragging the arrow to the package
representing the supplier.
1. Right-click to select the component package on the browser and make the shortcut menu
visible.
2. Select the Specification menu choice.
3. Select the Packages tab.
4. Right-click to select the logical package and make the shortcut menu visible.
5. Select the Assign menu choice.
6. Click the OK button to close the Specification.
Creating Components
1. Right-click to select the component on the browser and make the shortcut menu visible.
2. Select the Specification menu choice.
3. Select the Classes tab.
4. Right-click to select the class and make the shortcut menu visible.
5. Select the assign menu choice.
6. Click the OK button to close the Specification.
GVP College of Engineering for Women
1. Rose automatically creates the deployment diagram. To open the diagram, double-click on the
Deployment Diagram on the browser.
2. To create a node, click to select the Processor icon, and click on the diagram to place the
node.
3. With the node still selected, enter the name of the node.
4. To create a connection between nodes, click to select the connection icon from the toolbar,
click on one node on the deployment diagram, and drag the connection to the other node.
1. Create a project
2. Add Project Caption
3. Add Referenced Libraries and Base Projects
4. Set the File Type and Analyze the Files
5. Evaluate the Errors
6. Select Export Options and export to Rose 7. Update Rose Model.
GVP College of Engineering for Women
Event:
An event is an occurrence at a specific time and place that can be described and should
be remembered by the system. Events drive or trigger all processing that a system does, so
listing events and analyzing events makes sense when you need to define system requirements
by identifying use cases.
Event Decomposition is a technique analysts use to identify use cases by first focusing
on the events a system must respond to and then looking at how the system responds. The initial
view helps keep your focus on a high-level view of the system rather than on the inner workings
of the system. The external focus on events is appropriate when working with users. Focusing
on events gives you a way to divide the system requirements into use cases so you can study
each separately.
The importance of the concept of events for defining system requirements was first
emphasized for modern structured analysis when this concept was adapted to real-time systems
in the early 1980s. Use cases for business systems are now identified by using the event
decomposition approach.
Types of Events:
External Event:
An external event is an event that occurs outside of the system, usually initiated by an
external agent. An external agent is a person or organizational unit that supports or receives data
from the system, not necessarily the system user. To identify the external events, the analyst first
tries to identify all of the external agents that might want something from the system.
When describing external events, analysts need to name the event so that the external
agent is clearly defined. The description should also include the action that the external agent
wants to pursue. Important external events can also result from the wants and needs of people or
organizational units inside the company.
Another type of external event occurs when external entities provide new information
that the system simply needs to store for later use.
Temporal Events:
A second type of event is a temporal event, an event that occurs as a result of reaching a
GVP College of Engineering for Women
point in time.Many information systems produce outputs at defined intervals, such as payroll
systems that produce a paycheck every two weeks.
These events are different from external events in that the system should automatically
produce the required output without being told to do so.
Temporal events do not have to occur on a fixed date. They can occur after a define
period of time has elapsed.
State Events:
A State Event is an event that occurs when something happens inside the system that
triggers the need for processing.
Often State Events occur as a consequence of external events. Sometimes they are
similar to Temporal Events, except that the point in time cannot be defined.
Identifying Events:
It is always useful in identifying events to trace the sequence of events that might occur
for a specific external agent.
Sometimes the analyst is concerned about events that are important to the system but do
not directly concern users or transactions. Such events typically involve design choices or
system controls. When defining requirements, the analyst should temporarily ignore these
events. They are important for the design discipline, however.
Events that affect design issues include external events that involve actually using the
physical system, such as logging on. Most of these events include system controls, which are
checks or safety procedures put in place to protect the integrity of the system.
One technique used to help decide which events apply to controls is to assume that technology is
perfect. The perfect technology assumption states that events should be included during the
definition of requirements only if the system would be required to respond under perfect
conditions.
GVP College of Engineering for Women
Temporal Events:
Use case diagrams are a set of use cases, actors and their relationships. They represent
the use case view of a system.A use case diagram is a graphic depiction of the interactions
among the elements of a system.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. So when a system
is analyzed to gather its functionalities use cases are prepared and actors are identified.
Actor:
An actor specifies a role played by a user or any other system that interacts with the
subject.
Primary Actor:
The primary actor of a use case is the stakeholder that calls on the system to deliver one
of its services. It has a goal with respect to the system – one that can be satisfied by its
operation. The primary actor is often, but not always, the actor who triggers the use case.
Supporting Actors:
A supporting actor in a use case in an external actor that provides a service to the system
under design. It might be a high-speed printer, a web service, or humans that have to do some
research and get back to us.
Secondary Actors:
Secondary actors may or may not have goals that they expect to be satisfied by the use
case, the primary actor always has a goal, and the use case exists to satisfy the primary actor.
Use Case:
A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements. The use case is made up of a set of possible sequences of interactions
between systems and users in a particular environment and related to a particular goal. It
consists of a group of elements (for example, classes and interfaces) that can be used together in
a way that will have an effect larger than the sum of the separate elements combined. The use
case should contain all system activities that have significance to the users. A use case can be
thought of as a collection of possible scenarios related to a particular goal, indeed, the use case
and goal are sometimes considered to be synonymous.
GVP College of Engineering for Women
When it comes to drawing use case diagrams one area many struggle with is showing
various relationships in use case diagrams. In fact many tend to confuse <<extend>>,
<<include>> and generalization.
This one is straightforward and present in every use case diagram. Few things to note.
Generalization of an Actor:
Generalization of an actor means that one actor can inherit the role of an other actor.
The descendant inherits all the use cases of the ancestor. The descendant have one or more use
GVP College of Engineering for Women
cases that are specific to that role. Lets expand the previous use case diagram to show the
generalization of an actor.
Many people confuse the extend relationship in use cases. As the name implies it
extends the base use case and adds more functionality to the system. Here are few things to
consider when using the <<extend>> relationship.
The extending use case is dependent on the extended (base) use case. In the below
diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit
Funds” use case.
The extending use case is usually optional and can be triggered conditionally. In the
diagram you can see that the extending use case is triggered only for deposits over
10,000 or when the age is over 55.
The extended (base) use case must be meaningful on its own. This means it should be
independent and must not rely on the behavior of the extending use case.
Although extending use case is optional most of the time it is not a must. An extending
use case can have non optionalbehavior as well. This mostly happens when your modeling
complex behaviors.
For example in an accounting system one use case might be “Add Account Ledger
Entry”. This might have extending use cases “Add Tax Ledger Entry” and “Add Payment
Ledger Entry”. These are not optional but depend on the account ledger entry. Also they have
their own specific behavior to be modeled as a separate use case.
Include relationship show that the behavior of the included use case is part of the
including (base) use case.
GVP College of Engineering for Women
The main reason for this is to reuse the common actions across multiple use cases. In
some situations this is done to simplify complex behaviors. Few things to consider when using
the <<include>> relationship.
A catalogue of use cases that lists events in rows and key pieces of information about
each event in columns is an event table. Each row in the table records information about one
event and its use case. Each column in the table represents a key piece of information about that
event and use case.
An event table consists of the following: event, trigger, source, use case, response and
destination.
Event:
An event is the specification of a significant occurrence that has a location in time and
space. Anything that happens is modelled as an event. In the context of state machines, an event
is an occurrence of a stimulus that can trigger a state transition of an object or a group of
objects. Events can, but do not necessarily, cause state transitions from one state to another in
state machines represented by state machine diagrams.
Trigger:
A signal that tells the system that an event has occurred, either the arrival of data
needing processing or a point in time. It is a named element which is used to relate specific
event to a behaviour that may affect an instance of the classifier.
Events may cause execution of behaviours. A trigger specifies the event that may trigger
a behaviour execution. Each trigger is associated with exactly one event.
Source:
An external agent that supplies data to the system is source.
Use case:
It is a list of actions or event steps defining the interactions between a role (actor) and a
system to achieve a goal.
Response:
An output, produced by the system that goes to a destination is response.
Destination:
An external agent that receives data from the system is destination. It is the place where
any response (output) is sent, again an external event.
S.N DESTINATIO
EVENT TRIGGER SOURCE USE-CASE RESPONSE
O N
user should enter user registration of user will get
1 user LMS
register details the user credentials
enter user
user should should be valid
2 id,passwo user user login LMS
login user
rd
user search
book
for book search for
3 user avaialability user
availability of inquiry book
details
book
user request request
request for
4 for book issue status user request details LMS
book
details
viewing
user view history book status
5 user history of user
history details details
book
request
user request request for book request
6 book user LMS
for librarian book details
details
librarian issue issue book issue of book user gets
7 LMS user
book to user details to user requested book
librarian
catalog update updated ctalog
8 update LMS LMS
details catalog details
catalog
9 librarian request LMS requested due book vendor
request book book books for details
GVP College of Engineering for Women
librarian checking
checking
14 check for due details LMS status of due LMS
due details
due date date
returning
user returns return book book status
15 book user LMS
book to library details
details
librarian
calculating
16 calculates fine details LMS fine details LMS
fine
fine
fine
user pays paying fine to
17 fine details user payment LMS
fine librarian
details
payment is acknowledg
payment
payment correct or not ement
18 acknowled LMS -
details payment
ment
details
GVP College of Engineering for Women
Domain Class
Business objects - represent things that are manipulated in the business e.g. Order.
Real world objects – things that the business keeps track of e.g. Contact, Site.
Events that transpire - e.g. sale and payment.
Start the creation of a domain model by making a list of candidate conceptual classes.
Table contains many common categories that are usually worth considering, though not in any
GVP College of Engineering for Women
particular order of importance. Examples are drawn from the store and airline reservation
domains.
Vision and Scope, Glossary and Use Cases are good for this type of linguistic analysis
Noun phrases may also be attributes or parameters rather than classes:
Some of these noun phrases are candidate conceptual classes, some may refer to
conceptual classes that are ignored in this iteration and some may be attributes of conceptual
classes.
CatLog Activity Reports An output that can be performed from another information
e ) Represent use cases and a domain class diagram using Rational Rose.
CRUD Matrix:
In computer programming, create, read, update and delete (as an acronym CRUD)
are the four basic functions of persistent storage.Alternate words are sometimes used when
defining the four basic functions of CRUD, retrieve instead of read, modify instead of update, or
destroy instead of delete. CRUD is also sometimes used to describe user interface conventions
GVP College of Engineering for Women
that facilitate viewing, searching, and changing information; often using computer-based forms
and reports.
Another variation of CRUD is BREAD, an acronym for "Browse, Read, Edit, Add,
Delete".This extension is mostly used in context with data protection concepts, when it is legally
not allowed to delete data directly. Locking the data prevents the access for users without
destroying still needed data. Yet another variation, used before CRUD became more common,
is MADS, an acronym for "Modify, Add, Delete, Show.
Database Applications:
The acronym CRUD refers to all of the major functions that are implemented in
relational database applications. Each letter in the acronym can map to a standard SQL
statement, HTTP method
User Interface:
CRUD is also relevant at the user interface level of most applications. For example, in
address book software, the basic storage unit is an individual contact entry. As a bare minimum,
the software must allow the user to
Without at least these four operations, the software cannot be considered complete.
Because these operations are so fundamental, they are often documented and described under
GVP College of Engineering for Women
Order
Order Transaction Return
Usecases Catalog User Request Librarian Order Payment Vendor
item Item
Look up item
availabilty R
Create book
request CRU R R C C C
Update book
request RU RUD RUD
Provide catalog
information R R CRUD
Creates new
catalog C C
Receives new
order R R CR CRU R
Look up order
status R R R R
Update catalog CRUD
Create return
request R R R
Collect payment RU RU
WEEK – 5 & 6
WEEK – 5 & 6
WEEK – 5 & 6
UML provides two types of diagrams for the representation of interactions: the
sequence diagram and the communication diagram. Both diagrams visualize the exchange of
information. However, the emphasis is different: communication diagrams emphasize the
relationships of individual objects and their topology; sequence diagrams emphasize the
chronological course of exchanged information. In the external view, we opt for the
GVP College of Engineering for Women
representation through sequence diagrams and do without communication diagrams for two
reasons:
Sequence diagrams are easier to understand for developers and readers. In our practical
work in projects we have observed a much higher acceptance of sequence diagrams
because of their simplicity.
We avoid using unnecessarily many diagram types for the same facts. Less is often
more.
Objects
-this box shape with an underlined title represents a class, or object, in UML. Within a
SSD, this shape models the system as a black box (a system with inner workings that are not
immediately visible).
Actors
-shown by stick figures, actors are entities that interact with the system, and yet
are external to it.
Events
-the system events that the actors generate in the sequence. A dashed line, known as a
lifeline, represents events in an SSD. Lifelines may begin with a labeled rectangle shape or an
actor symbol.When to Draw a System Sequence DiagramSSDs are ideal for demonstrating
when and how tasks are completed in a system, especially as those tasks are related to use
case.
Lifelines:
When drawing a sequence diagram, lifeline notation elements are placed across the top
of the diagram. Lifelines represent either roles or object instances that participate in the
sequence being modeled. [Note: In fully modeled systems the objects (instances of classes) will
also be modeled on a system's class diagram.] Lifelines are drawn as a box with a dashed line
descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside
the box.
Example:
GVP College of Engineering for Women
The following diagram has shown the message sequence for SpecialOrder object and
the same can be used in case of NormalOrder object. Now it is important to understand the time
sequence of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call isconfirm
() which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another.
Issue Books
Renewal Books
GVP College of Engineering for Women
Return Books
Supply Books
GVP College of Engineering for Women
Model - The lowest level of the pattern which is responsible for maintaining data.
View - This is responsible for displaying all or a portion of the data to the user.
Controller - Software Code that controls the interactions between the Model and View.
MVC is popular as it isolates the application logic from the user interface layer and
supports separation of concerns. Here the Controller receives all requests for the application
and then works with the Model to prepare any data needed by the View. The View then uses
the data prepared by the Controller to generate a final presentable response. The MVC
abstraction can be graphically represented as follows.
GVP College of Engineering for Women
MODEL:
The model is responsible for managing the data of the application. It responds to the
request from the view and it also responds to instructions from the controller to update itself.
VIEW:
A presentation of data in a particular format, triggered by a controller's decision to
present the data. They are script based templating systems like JSP, ASP, PHP and very easy to
integrate with AJAX technology.
CONTROLLER:
The controller is responsible for responding to user input and perform interactions on
the data model objects. The controller receives the input, it validates the input and then
Issue books:
<<view>>
<<controlling>> <<model>>
user
librarian catalogue
Return books:
Order books:
<<control>> <<control>>
librarian vender
Supply books:
<controller>> <<controller>>
librarian vender
Renewal:
<<view>> <<controller>>
user librarian
A class diagram in the unified modelling language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system’s classes, their attributes,
operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modelling. It is used
both for general conceptual modelling of the systematic of the application, and for detailed
modelling translating the models into programming code. Class diagrams can also be used for
data modelling. The classes in a class diagram represent both the main elements, interactions in
the application, and the classes to be programmed.
The top compartment contains the name of the class. It is printed in bold and centred,
and the first letter is capitalized.
The middle compartment contains the attributes of the class. They are left-aligned and
the first letter is lowercase.
GVP College of Engineering for Women
The bottom compartment contains the operations the class can execute. They are also
left-aligned and the first letter is lowercase.
In the design of a system, a number of classes are identified and grouped together in a
class diagram that helps to determine the static relations between them. With detailed modelling,
the classes of the conceptual design are often split into a number of subclasses.
The class diagrams are linked by relationship. A relationship is a general term covering
the specific types of logical connections found on class and objects diagrams. They are of 5
types. They are:
Association
Generalisation
------------Dependency
------------- Realization
Attribute:
Package diagram is UML structure diagram which shows structure of the designed
system at the level of packages. The following elements are typically drawn in a package
diagram: package, packageable element, dependency, element import, package import, package
merge.(UML Package Diagram is a type of Structure Diagrams that represents the packages of
the model and dependencies between them.)
Package Diagrams are used to illustrate the layered architecture of a software system.
The packages depict the different layers of a software system. To indicate the types of
dependencies between the packages are used the stereotypes.
There are two special types of dependencies between the packages in UML:
package import and package merge.
1. Package: a general purpose mechanism for organizing model elements & diagrams into
groups. It provides an encapsulated namespace within which all the names must be unique. It is
used to group semantically related elements. It is a namespace as well as an element that can be
contained in other packages' namespaces.
2. Class: a representation of an object that reflects its structure and behavior within the system.
It is a template from which running instances are created. Classes usually describe the logical
structure of the system.
4. Object: an instance of a class. It is often used in analysis to represent an artifact or other item.
Usage:-
Package diagrams can use packages containing use cases to illustrate the functionality
of a software system.
* It is used in large scale systems to picture dependencies between major elements in the system
* Package diagrams represent a compile time grouping mechanism.
WEEK – 11 & 12
Explanation
If there are many use cases or actors, you can use use-case packages to further structure the
use-case model. A use-case package contains a number of actors, use cases, their
relationships, and other packages; thus, you can have multiple levels of use-case packages
(packages within packages).
The top-level package contains all top-level use-case packages, all top-level actors, and all
top-level use cases.
Use
You can partition a use-case model into use-case packages for many reasons:
You can use use-case packages to reflect order, configuration, or delivery units in the
finished system.
Allocation of resources and the competence of different development teams may require that
the project be divided among different groups at different sites. Some use-case packages are
suitable for a group, and some for one person, which makes packages a naturally efficient
way to proceed with development. You must be sure, however, to define distinct
responsibilities for each package so that development can be performed in parallel.
You can use use-case packages to structure the use-case model in a way that reflects the user
types. Many change requirements originate from users. Use-case packages ensure that
changes from a particular user type will affect only the parts of the system that correspond to
that user type.
In some applications, certain information should be accessible to only a few people. Use-case
packages let you preserve secrecy in areas where it is needed.
WEEK – 11 & 12
Now the question is what are these physical aspects? Physical aspects are the elements
like executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.
Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different
from all other diagrams discussed so far. It does not describe the functionality of the system but
it describes the components used to make those functionalities.
So from that point component diagrams are used to visualize the physical components
in a system. These components are libraries, packages, files etc.
A single component diagram cannot represent the entire system but a collection of
diagrams are used to represent the whole.
We have already described that component diagrams are used to visualize the static
implementation view of a system. Component diagrams are special type of UML diagrams
used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can say
that component diagrams describe the organization of the components in a system.
As we have already discussed those components are libraries, files, executables etc.
Now before implementing the application these components are to be organized. This
component organization is also designed separately as a part of project execution.
\
GVP College of Engineering for Women
2. POINT-OF-SALE TERMINAL
WEEK - 11& 12
c)Identify relationships between use cases and represent them
GVP College of Engineering for Women
GVP College of Engineering for Women
WEEK – 11 & 12
d ) Refine domain class model by showing all the associations among classes .
2. POINT-OF-SALE TERMINAL
GVP College of Engineering for Women
WEEK – 13
a ) Develop sample diagrams for other UML diagrams – state chart diagrams,
activity diagrams and deployment diagrams.
The name of the diagram itself clarifies the purpose of the diagram and other details. It
describes different states of a component in a system. The states are specific to a
component/object of a system. A State Chart diagram describes a state machine.
Now to clarify it state machine can be defined as a machine which defines different
states of an object and these states are controlled by external or internal events. As State Chart
diagram defines states it is used to model lifetime of an object.
Purpose:
Before drawing a State Chart diagram we must have clarified the following points:
The following is an example of a State Chart diagram where the state of Order object is
analyzed.
The first state is an idle state from where the process starts. The next states are arrived for
events like send request, confirm request, and dispatch order. These events are responsible for
state changes of order object.
Activity Diagram:
So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.
Purpose:
GVP College of Engineering for Women
The basic purposes of activity diagrams are similar to other four diagrams. Other four
diagrams are used to show the message flow from one object to another but activity diagram is
used to show message flow from one activity to another. Activity is a particular operation of the
system. It captures the dynamic behaviour of the system. Activity diagrams are not only used
for visualizing dynamic nature of a system but they are also used to construct the executable
system by using forward and reverse engineering techniques. The only missing thing in activity
diagram is the message part.
Activities
Association
Conditions
Constraints
After receiving the order request condition checks are performed to check if it is normal
or special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.
GVP College of Engineering for Women
Deployment Diagram:
Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.So deployment diagrams are used to
describe the static deployment view of a system. Deployment diagrams consist of nodes and
their relationships.
Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams
are used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related. Component diagrams are
used to describe the components and deployment diagrams shows how they are deployed in
hardware.
Performance
Scalability
Maintainability
Portability
GVP College of Engineering for Women
Nodes
b)pos
GVP College of Engineering for Women
GVP College of Engineering for Women
c)lms
GVP College of Engineering for Women
GVP College of Engineering for Women
GVP College of Engineering for Women
GVP College of Engineering for Women