ML 2 use case diagrams overview the usage requirements for a system.

They are useful for

presentations to management and/or project stakeholders, but for actual development you will find
that use cases provide significantly more value because they describe "the meat" of the actual
requirements. Figure 1 provides an example of a UML 2 use case diagram.

Use case diagrams depict:

• Use cases. A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.
• Actors. An actor is a person, organization, or external system that plays a role in one or more
interactions with your system. Actors are drawn as stick figures.
• Associations. Associations between actors and use cases are indicated in use case diagrams by
solid lines. An association exists whenever an actor is involved with an interaction described by a
use case. Associations are modeled as lines connecting use cases and actors to one another, with
an optional arrowhead on one end of the line. The arrowhead is often used to indicating the
direction of the initial invocation of the relationship or to indicate the primary actor within the use
case. The arrowheads are typically confused with data flow and as a result I avoid their use.
• System boundary boxes (optional). You can draw a rectangle around the use cases, called the
system boundary box, to indicates the scope of your system. Anything within the box represents
functionality that is in scope and anything outside the box is not. System boundary boxes are
rarely used, although on occasion I have used them to identify which use cases will be delivered
in each major release of a system. Figure 2 shows how this could be done.
• Packages (optional). Packages are UML constructs that enable you to organize model elements
(such as use cases) into groups. Packages are depicted as file folders and can be used on any of
the UML diagrams, including both use case diagrams and class diagrams. I use packages only
when my diagrams become unwieldy, which generally implies they cannot be printed on a single
page, to organize a large diagram into smaller ones. Figure 3 depicts how Figure 1 could be
reorganized with packages.

In the example depicted in Figure 1 students are enrolling in courses with the potential help of registrars.
Professors input the marks students earn on assignments and registrars authorize the distribution of
transcripts (report cards) to students. Note how for some use cases there is more than one actor involved.
Moreover, note how some associations have arrowheadsany given use case association will have a zero
or one arrowhead. The association between Student and Enroll in Seminar (in the version shown in Figure
4) indicates this use case is initially invoked by a student and not by a registrar (the Registrar actor is also
involved with this use case). Understanding that associations don’t represent flows of information is
important; they merely indicate an actor is somehow involved with a use case. Information is flowing
back and forth between the actor and the use case, for example, students would need to indicate which
seminars they want to enroll in and the system would need to indicate to the students whether they have
been enrolled. However, use case diagrams don’t model this sort of information. Information flow can be
modeled using UML activity diagrams. The line between the Enroll in Seminar use case and the
Registrar actor has no arrowhead, indicating it is not clear how the interaction between the system and
registrars start. Perhaps a registrar may notice a student needs help and offers assistance, whereas other
times, the student may request help from the registrar, important information that would be documented
in the description of the use case. Actors are always involved with at least one use case and are always
drawn on the outside edges of a use case diagram.
Figure 1. System use case diagram.

Figure 2. Using System boundary boxes to indicate releases.

Figure 3. Applying packages to simplify use case diagrams.

Creating Use Case Diagrams

I like to start by identifying as many actors as possible. You should ask how the actors interact with the
system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use
cases with which they are involved. If an actor supplies information, initiates the use case, or receives any
information as a result of the use case, then there should be an association between them. I generally
don’t include arrowheads on the association lines because my experience is that people confuse them for
indications of information flow, not initial invocation. As I begin to notice similarities between use cases,
or between actors, I start modeling the appropriate relationships between them (see the Reuse
Opportunities section).

The preceding paragraph describes my general use case modeling style, an “actors first” approach.
Others like to start by identifying one actor and the use cases that they’re involved with first and then
evolve the model from there. Both approaches work. The important point is that different people take
different approaches so you need to be flexible when you’re following AM’s practice of Model With
Others.

Reuse Opportunities

Figure 4 shows the three types of relationships between use cases -- extends, includes, and inheritance --
as well as inheritance between actors. I like to think of extend relationships as the equivalent of a
"hardware interrupt" because you don't know when or if the extending use case will be invoked (perhaps a
better way to look at this is extending use cases are conditional). Include relationships as the equivalent
of a procedure call. Inheritance is applied in the same way as you would on UML class diagrams -- to
model specialization of use cases or actors in this case. The essay Reuse in Use Case Models describes
these relationships in greater detail.

Figure 4. Use case reuse.

Remaining Agile

So how can you keep use case modeling agile? First, focus on keeping it as simple as possible. Use
simple, flexible tools to model with. I’ll typically create use case diagrams on a whiteboard, as you see in
Figure 5 which is an example of an initial diagram that I would draw with my project stakeholders. AM
tells us that Content is More Important Than Representation so it isn’t a big issue that the diagram is hand
drawn, it’s just barely good enough and that’s all that we need. It’s also perfectly okay that the diagram
isn’t complete, there’s clearly more to a university than what is depicted, because we can always modify
the diagram as we need to.

Figure 5. Whiteboard sketch.

In parallel to creating the sketch I would also write a very brief description of each use case, often on a
whiteboard as well. The goal is to record just enough information about the use case so that we
understand what it is all about. If we need more details we can always add them later either as an
essential/business use case or a system use case.
UML Use Case Diagrams: Tips and FAQ

Contents:

What is a UML Use Case Diagram (UCD), and when should I use it?
How do you know who the actors are in a UCD?
How do you know what to put in the "System" box?
The actors in my diagram have interactions. How do I represent them?
I am trying to represent a sequence of actions that the system performs. How do I
do it?
How is a UML Use Case Diagram different from a traditional flow chart?
When do I use the uses arrow?
When do I use the extends arrow?
What is the difference between uses and extends?
The scenario I want to describe branches into several possible outcomes, or has
some error conditions. How can I represent that with Use Case Diagrams?

What is a UML Use Case Diagram (UCD), and when should I use it?

UML Use Case Diagrams can be used to describe the functionality of a system in a
horizontal way. That is, rather than merely representing the details of individual
features of your system, UCDs can be used to show all of its available functionality.
It is important to note, though, that UCDs are fundamentally different from
sequence diagrams or flow charts because they do not make any attempt to
represent the order or number of times that the systems actions and sub-actions
should be executed. There are a number of graphical examples in this FAQ; you
might want to look over them to familiarize yourself with the look of them.

UCDs have only 4 major elements: The actors that the system you are describing
interacts with, the system itself, the use cases, or services, that the system knows
how to perform, and the lines that represent relationships between these
elements.

You should use UCDs to represent the functionality of your system from a top-down
perspective (that is, at a glance the system's functionality is obvious, but all
descriptions are at a very high level. Further detail can later be added to the
diagram to elucidate interesting points in the system's behavior.)
Example: A UCD is well suited to the task of describing all of the things that can be
done with a database system, by all of the people who might use it (administrators,
developers, data entry personnel.)
You should NOT use UCDs to represent exception behavior (when errors happen) or
to try to illustrate the sequence of steps that must be performed in order to
complete a task. Use Sequence diagrams to show these design features.
Example: A UCD would be poorly suited to describing the TCP/IP network protocol,
because there are many exception cases, branching behaviors, and conditional
functionality (what happens when a packet is lost or late, what about when the
connection dies?)

Back to top

How do you know who the actors are in a UCD?

When working from an Action/Response table, itentifying the actors is easy: entities
whose behavior appears in the "Actor's Actions" column are the actors, and entities
whose behavior appears in the "System's Response" column are components in the
system.

If you are working from an informal narrative, a sequence diagram, or a scenario

description, the actors are typically those entities whose behavior cannot control or
change (i.e., agents that are not part of the system that you are building or
describing.) The most obvious candidates for actors are the humans in the system;
except in rare cases when the system you are describing is actually a human
process (such as a specific method of dealing with customers that employees
should follow) the humans that you must interact with will all be actors. If your
system interacts with other systems (databases, servers maintained by other
people, legacy systems) you will be best to treat these as actors, also, since it is not
their behavior that you are interested in describing.
Example: When adding a new database system to manage a company's finances,
your system will probably have to interface with their existing inventory
management software. Since you didn't write this software, don't intend to replace
it, and only use the services that it provides, it makes sense for that system to be
an actor.

Back to top

How do you know what to put in the "System" box?

The system box only appears on the top-level diagram (remember that a typical
UML Use Case description will be composed of many diagrams and sub-diagrams),
and should contain use case ovals, one for each top-level service that your system
provides to its actors. Any kind of internal behavior that your system may have that
is only used by other parts of the system should not appear in the system box. One
useful way to think of these top-level services is as follows: if a use case represents
a top-level service, then it should make sense for the actors who interact with it to
request only that service of your system in a single session (in whatever sense a
"session" is intelligible in your system.)

Example: In the diagram below we would like to represent the use cases for a
camera. Suppose we choose "Open Shutter", "Flash", and "Close Shutter" as the
top-level use cases. Certainly these are all behaviors that a camera has, but no
photographer would ever pick up their camera, open the shutter, and then put it
down, satisfied with their photographic session for the day. The crucial thing to
realize is that these behaviors are not done in isolation, but are rather a part of a
more high-level use case, "Take Picture". (Note that it does make sense for a
photographer to "Take Picture" just once during a session with their camera.)
Back to top

The actors in my diagram have interactions. How do I represent them?

If there are interactions between the actors in your system, you cannot represent
those interactions on the same diagram as your system. What you can do instead is
draw a separate UCD, treating one of the actors itself as a system, and your original
system (along with the other actors) as actors on this new diagram.

Example: Suppose you wanted to diagram the interactions between a user, a web
browser, and the server it contacts. Since you can only have one system on the
diagram, you must choose one of the obvious "systems", such as the server. You
might then be tempted to draw interaction lines between the actors, but this is a
problem because it isn't clear what the interaction means, so it isn't helpful to show
it here. A more useful solution would be to draw two diagrams, showing all of the
interactions, as below.
Back to top

I am trying to represent a sequence of actions that the system performs. How do

I do it?

Using a UML Use Case Diagram, you can't. UCDs are meant to be a top-down,
horizontal description of functionality, not a blow-by-blow desrciption of behavior.
For the most part, it isn't a good idea to try to represent sequences of actions with
Use Case diagrams. You should use a Sequence Diagram or a traditional flow chart
instead. (It is possible to represent simple branching conditions with a UCD, as
described below, but you should use this technique sparingly because it can render
a diagram unreadable.)

Back to top

How is a UML Use Case Diagram different from a traditional flow chart?

As mentioned above, UCDs represent functionality in a top-down way, whereas flow

charts represent behavior in a linear, time-based way. Also, the way you develop
them is all-together different.

Example: (This text refers to the diagrams below.) When constructing a UCD, the
initial step is to identify all of the top-level behavior. Once you have done this (not a
very tricky process) you have already described, at least in a high-level way, all of
the things your system knows how to do. You can then continue to add detail by
decomposing your use cases into more use cases which are used by the top-level
use cases. At every stage of development, though, your UCD is a complete
description of the system's functionalty: it may lack detail, but it will not lack
feature set elements. And if functionality or behavior is added or deleted over the
life of your project, the scope of the change you need to make is proportional to
both the scope of the change in the system itself, and the maturity of your model.
This is useful because it means that when your model is very young (only high-level
diagrams drawn) making sweeping changes to the system does not involve
throwing very much work away. A flow chart, however, does not correctly describe
the system until you have finished drawing it, and even then small changes in the
system will result in significant reworking of your flow charts. In general, UCDs
support the process of analysis and design much better than flow charts.
Back to top

When do I use the uses arrow?

The uses arrow (or uses edge as it would be called in traditional graph thoery) is
drawn from a use case X to another use case Y to indicate that the process of doing
X always involves doing Y at least once (although it may involve doing it many
times, "at least once" is the only relationship guaranteed by this symbol.) This
symbol can be referred to as an aggregation operator, because it indicates that a
given use case is an aggregate (made up of parts) whose components are the use
cases that it uses. If a certain use case uses several others, that means that all of
the component use cases must be completed in the process of completing the
aggregate use case, although there is no specification in UCDs of the order in which
these are completed. A brief, mnemonic way to think about the uses arrow is that it
it can be read X uses Y means that "X has a Y" as part of it's behavior.
Example: Suppose you wanted to add detail to the diagram shown below,
representing an airline reservation system. First, you would create a separate
diagram for the top-level services, and then you would add new use cases that
make up the top-level ones. There is a uses edge from "Check in Passenger" to
"Weigh Luggage" and from "Check in Passenger" to "Assign Seat"; this indicates
that in order to Check in a Passenger, Luggage must be Weighed and a Seat must
be Assigned. Similarly, the diagram indicates that in order to add a reservation to
the system, the available space must be checked and the passenger's information
must be recorded. You could imagine breaking these use cases down further to
show more detail.
Back to top

When do I use the extends arrow?

The extends arrow (or extends edge) is drawn from a use case X to a use case Y to
indicate that the process X is a special case behavior of the same type as the more
general process Y. You would use this in situations where your system has a number
of use cases (processes) that all have some subtasks in common, but each one has
something different about it that makes it impossible for you to just lump them all
together into the same use case.

Example: Suppose you wanted to add detail to the diagram shown below,
representing an airline reservation system. Specifically, what you would like to show
is that not all of the seats aboard the airplane are exactly alike (some window and
some aisle seats), and sometimes passengers will express a preference for one of
these types of seats but not the other. But of course, they cannot just be given their
preference right away, because the seat they want might not be available.
Therefore, the process of assigning a window seat involves checking for the
availability of window seats, whereas the process of assigning an aisle seat involves
checking for the availability of aisle seats. But even though these processes are
different, they are quite similar in a number of other ways, so it doesn't make sense
to ignore their similarities. Fortunately, UML lets us have both: we write that
assigning these two types of seats are different processes, but they are similar in
that both processes extend a common, more general process (assigning seats.)
Back to top

What is the difference between uses and extends?

Probably the best way to think about these diagram elements is as follows:

- "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in the process of
completing task "X", task "Y" will be completed at least once.

- "X extends Y" indecates that "X" is a task fo the same type as "Y", but "X" is a
special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X
has a few extra processes to it that go above and beyond the things that must be
done in order to complete Y.

Example:indicates that inorder to successfully "Check-in", you must "Weigh

luggage" and "Assign a seat", some number of times, in some order. The key,
though, is that all UCs used by a use case MUST BE DONE before that use case be
considered to be complete. Once you realize that there are several types of seat
assignment, you might be tempted to draw a diagram using the uses edge like the
one below, but this doesn't make sense: This diagram says that in order to assign a
seat you must assign both a window seat AND an aisle seat to the passenger. Never
fear, however; this situation is correctly handled by the extends relationship. Using
the extends relationship (as shown in the following diagram), we can express that
there are two ways to assign a seat: assigning a window seat and assigning an aisle
seat, but only one need be completed in the process of assigning the passenger a
seat.

Back to top
The scenario I want to describe branches into several possible outcomes, or has
some error conditions. How can I represent that with Use Case Diagrams?

Representing failure and branching conditions is often best done with a Sequence
Diagram or flow chart, but there are some grey-area cases when it isn't clear
whether or not a Use Case Diagram is appropriate. A rule of thumb: if in
representing the branching actions in the Use Case Diagram you must add
significantly more use case ovals, and the resulting diagram is muddy or confusing,
consider using a different diagramming style.

With that said, it is possible to represent simple branching behavior with UCDs,
although I would like to again stress that UCDs ARE NOT FLOW CHARTS. This is
done by realizing that if the use case, or process that you are trying to represent
can have two significantly different outcomes (success and failure, for example),
then that means that you really have two different use cases: one in which the
process succeeds, and one in which the process fails. Of course, these two use
cases are related in that they are both extensions of the original use case, so you
would draw the original use case with the two branches extending from it. I consider
this almost an abuse of the meaning of the extends edge, because it really isn't
being used here to represent a taxonomy of use cases (which is its purpose) but is
instead taking advantage of the specific abstract definition of the relation to hack
flow-chart-like behavior out of the UCD style. Again, USE THIS TECHNIQUE
SPARINGLY; IT CAN QUICKLY MAKE A DIAGRAM UNREADABLE.

Example: Suppose that we want to represent the use cases of a normal CD player.
When all goes well, the CD player retracts the tray upon which the CD sits, reads it,
and starts playing. (The use case for this behavior is represented below. The top-
level diagram has been omitted for brevety.) Unfortunately, some users will
command the system to play a CD even when there is no CD in the tray. We
therefore have a failure condition, under which the system must do something other
than play the CD (namely, prompt the user for a CD.) To represent this, we modify
the normal diagram with some extra use cases, in which the presence of the CD is
verified. The behavior of playing the CD extends the behavior of verifying that the
CD is present in that it is the special case of verifying the CD's presence in which
the CD is present. The other special case of verifying the CD's presence is that this
is done and the CD is not present, so the user is prompted for a CD. I will say one
last time that this use of extension is a bit of a reach, but it is an elegant way to
express multiple behaviors of a single use case when the number of such behaviors
is small.
Back to top
The main additions to the system are:
• Ability to search for most things by dates.

• Ability for manager to configure dates for terms.

• Quick date search system added by clicking on the term you want to search within.

• Configurable search levels for the teacher section. i.e restrict searches to either only
students, students and teachers or students, teachers and administrators.

• Greatly enhanced Student section. Standardized tests, Activities,Awards, Grades and

Attendance added to the area.

• Searching grades now averages the percentage results. - you can use this to find average
marks of students during a term.

• Graphs now work using the date search information

• Financial system added that has the abilty to compute total amount paid and owed by a
search group. The financial system also has the ability to print pdf invoices.

• Tutorials or instructions added for teachers and students to course delivery system. Enrol
students or teachers in these courses and instructions on using SchoolMation can be
found through the organiser course section of SchoolMation

• Tutorials for administrators and managers coming soon.

SchoolMation Transcript 1.1 released

This is a companion product to SchoolMation and allows the storing of relevant data over many
years in a separate database.
This information can be viewed in many ways and PDF customised reports can be created.

The change log file for the transcript system is at the bottom of the SchoolMation change log
file.

Price Information
Price information for both these products can be found here.

What is SchoolMation?
SchoolMation is school administration software or school management software.
SchoolMation is a full-featured web-based software application. It allows schools to easily, and
affordably manage student data online. Unlike separate grade book programs, stand-alone course
delivery software, and solutions made by “sticking” a bunch of different programs together,
SchoolMation is built from the ground up to be a comprehensive and integrated application.

SchoolMation incorporates such features as: full student/course details, flexible attendance
system, weighted grades, grade calculator, discipline tracking, master schedule, PDF printable
individual schedules, internal messaging system, PDF printable multiple custom report card
options, multimedia course delivery/management, custom searches, reports and statistics, user
defined list creation, custom access levels, XML data importing/exporting, and more.

SchoolMation, designed specifically by experienced educators, to meet the hands-on demands of

real schools, has a proven track record. First released in 1997 as a web-based alternative to
expensive proprietary systems, SchoolMation’s growing user-base now spreads across the world.
SchoolMation, included in “Scholastic Administrator Magazine’s” list of ten top student
information systems in October 2003, has been upgraded again to deliver more user requested
functionality while retaining its characteristic ease-of-use.

It is our goal to remain the most cost-effective, full-featured student management system
available to schools anywhere. Many alternatives to SchoolMation claim to be web-based, but in
reality, they are only web-enabled. What this means is that you still have to run “proprietary”
software on certain computers and there are usually some important things that can’t be done
using a standard web-browser. SchoolMation is 100% web-based. Everything your need to do
can be done via a standard web-browser such as Internet Explorer. It is that simple.
As a school, you have the ability to easily configure SchoolMation to fit within your guidelines
and practices. For example, you can decide whether parents should be given online access to
their son/daughter’s information, and if so, exactly what information they should be allowed to
view. Software should not dictate how you need to run your school, and that is why we have
built SchoolMation to be as flexible as possible.

Since FullSite, the developers of SchoolMation, have written the entire code from the ground up,
if there are additional features you wish to incorporate or custom changes you would like to
have, we will do our best to accommodate. SchoolMation works as an “out-of-the-box”
application, but we are more then happy to provide free quotations for any special requests you
may have. We also offer a range of optional services to help you get up and running quickly.

SchoolMation provides simple access to all important school information, which allows you to
make knowledge-driven decisions. We invite you to learn more about SchoolMation by
exploring our site. Please contact us if we can be of further assistance. SchoolMation is a product
of FullSite Pty Ltd, which is headquartered in Sydney, Australia. All prices are in Australian
Dollars.

Online Demo is here

• Version 2.3 (pdf and transcript version) of SchoolMation is now online and
available for you to evaluate. A demonstration of the transcript system will be
available soon

• The passwords to enter it are

Student Section
userid = student
 password = car
Teacher Section
userid = teacher
password = bus
Administrator Section
userid = admin
password = train
Manager Section
userid = manager
password = ship

Toolbox for IT

Topics

Wiki

EditDiscussHistoryInvite PeersConnect

Parent Categories: Project Lifecycle | Plm-select

Major Editors: akshaya bhatia bcmfh

All Editors

V-Model
updated Oct 27, 2007 4:42 pm | 12,771 views

V-model is a software development model that is based on the relationships between each phase of the development
life cycle as described in a typical Waterfall model of software development and its associated phase of testing.

The V-model involves building a logical V shape sequence where the testing techniques associated with the design
are reflected as descending and are applied for the “verification” and connected to the the requirements or
specifications parts are reflected as ascending and are applied for “validation”.

The V-model gives equal weight to coding and testing in a software development process.The V-model ordains that
the code testing documentation is written in tandem with the development phases that means,for instance, the
integration tests should be documented as and when the high level design is finalized and the unit tests should be
ready as and when the detailed specifications are laid down.

The idea of the V-model is to have a implementation plan for the software testing at each level namely component,
interface,system,acceptance and release of the software project which need to be adhered to eliminate discrepancies
in the software simultaneouly rather than waiting for the software development process to complete before handling it
to the the software testing professionals.

The V-Model is a Software life cycle model.

It explains, how you go from high level concept to released product.

 At the top of the left V line, is the High level concepts.

 At the bottom of the V is the coding phase.
 At the top right V line is the released product.

The reason for calling it a V is because most of the phases on the left has a corresponding phase of activity on the
right.

E.g. Detailed design is done along side unit testing planing.

1. High level business plan. Market analysis e.t.c.

2. Product requirements. Also do system test requirements.
3. Architectual and highlevel design. Also do box testing and intergration test requirements.
4. Detailed design
5. Coding.
6. Unit testing.
7. Integration and testing.
8. System Testing.
9. Product operation and maintenance.