USE CASES:

A use case in software engineering and systems engineering is a description of a system’s behaviour as it
responds to a request that originates from outside of that system. In other words, a use case describes "who"
can do "what" with the system in question. The use case technique is used to capture a system's behavioral
requirements by detailing scenario-driven threads through the functional requirements.Within systems
engineering, use cases are used at a higher level than within software engineering, often representing
missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement
diagrams or similar mechanisms.

Business vs. System Use Cases

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or
at the system level (system use case). The differences between these is the scope.

• A business use case is described in technology-free terminology which treats system as a black
box and describes the business process that is used by its business actors (people or systems
external to the process) to achieve their goals (e.g., manual payment processing, expense report
approval, manage corporate real estate). The business use case will describe a process that
provides value to the business actor, and it describes what the process does. Business Process
Mapping is another method for this level of business description.

• A system use case describes a system that automates a business use case or process. It is normally
described at the system functionality level (for example, "create voucher") and specifies the
function or the service that the system provides for the actor. The system use case details what the
system will do in response to an actor's actions. For this reason it is recommended that system use
case specification begin with a verb (e.g., create voucher, select payments, exclude payment,
cancel voucher). An actor can be a human user or another system/subsystem interacting with the
system being defined.

Degree of detail

• Brief use case consists of a few sentences summarizing the use case. It can be easily inserted in a
spreadsheet cell, and allows the other columns in the spreadsheet to record priority, duration, a
method of estimating duration, technical complexity, release number, and so on.

• Casual use case consists of a few paragraphs of text, summarizing the use case.

• Fully dressed use case is a formal document based on a detailed template with fields for various
sections; and it is the most common understanding of the meaning of a use case. Fully dressed use
cases are discussed in detail in the next section on use case templates.

Appropriate detail

Some software development processes do not require anything more than a simple use case to define
requirements. However, some other development processes require detailed use cases to define
requirements. The larger and more complex the project, the more likely that it will be necessary to use
detailed use cases.The level of detail in a use case often differs according to the progress of the project. The
initial use cases may be brief, but as the development process unfolds the use cases become even more
detailed. This reflects the different requirements of the use case. Initially they need only be brief, because
they are used to summarize the business requirement from the point of view of users. However, later in the
process, software developers need far more specific and detailed guidance.

The Rational Unified Process invites developers to write a brief use case description in the use case
diagram, with a casual description as comments and a detailed description of the flow of events in a textual
analysis. All those can usually be input into the use case tool (e.g., a UML Tool, SysML Tool), or can be
written separately in a text editor.

Use case templates

• Use case name
• Use case number
• Version
• Goal
• Summary
• Actors
• Stakeholders
• Preconditions
• Triggers
• Basic course of events
• Alternative paths or Exceptions
• Postconditions
• Business rules
• Notes
• Author and date

CLASS DIAGRAM:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a
type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the classes.
The class diagram is the main building block in object oriented modelling. It is used both
for general conceptual modelling of the systematics of the application, and for detailed
modelling translating the models into programming code. The classes in a class diagram
represent both the main objects and or interactions in the application and the objects to be
programmed. In the class diagram these classes are represented with boxes which contain
three parts: [1]
A class with three sections.

• The upper part holds the name of the class

• The middle part contains the attributes of the class

• The bottom part gives the methods or operations the class can take or undertake
In the system design of a system, a number of classes are identified and grouped together
in a class diagram which helps to determine the statical relations between those objects.
With detailed modeling, the classes of the conceptual design are often split in a number
of subclasses.
In order to further describe the behavior of systems, these class diagrams can be
complemented by state diagram or UML state machine. Also instead of class diagrams
Object role modeling can be used if you just want to model the classes and their
relationships.
Instance Level Relationships:
• External links
• Association
• Aggregation
• Composition

Class Level Relationships:

• Generalization
• Realization
General Relationship:
• Dependency
• Multiplicity

SEQUENCE DIAGRAM:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that shows
how processes operate with one another and in what order. It is a construct of a Message Sequence
Chart.Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.[1]
OVERVIEW:
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which
they occur. This allows the specification of simple runtime scenarios in a graphical manner.
For instance, the UML 1.x diagram on the right describes the sequences of messages of a (simple)
restaurant system. This diagram represents a Patron ordering food and wine, drinking wine then eating the
food, and finally paying for the food. The dotted lines extending downwards indicate the timeline. Time
flows from top to bottom. The arrows represent messages (stimuli) from an actor or object to other objects.
For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method
calls.The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x Sequence Diagram with
added support for modeling variations to the standard flow of events.

Diagram building blocks

If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance name blank can
represent anonymous and unnamed instances.

In order to display interaction, messages are used. These are horizontal arrows with the message name
written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are
asynchronous calls and dashed arrows with stick heads are return messages. This definition is true as of
UML 2, considerably different from UML 1.x.

Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that
processes are being performed in response to the message (ExecutionSpecifications in UML).

Objects calling methods on themselves use messages and add new activation boxes on top of any others to
indicate a further level of processing.

When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and the dashed
line ceases to be drawn below it (this is not the case in the first example though). It should be the result of a
message, either from the object itself, or another.

A message sent from outside the diagram can be represented by a message originating from a filled-in
circle (found message in UML) or from a border of sequence diagram (gate in UML).

UML 2 has introduced significant improvements to the capabilities of sequence diagrams. Most of these
improvements are based on the idea of interaction fragments[2] which represent smaller pieces of an
enclosing interaction. Multiple interaction fragments are combined to create a variety of combined
fragments[3], which are then used to model interactions that include parallelism, conditional branches,
optional interactions.

COLLABORATION:
A communication diagram in the Unified Modeling Language (UML) 2.0, is a simplified version of the
UML 1.x collaboration diagram.[1]

UML has four types of Interaction Diagrams:

• Sequence diagram

• Communication diagram
 • Interaction overview diagram

• Timing diagram

A Communication diagram models the interactions between objects or parts in terms of sequenced
messages. Communication diagrams represent a combination of information taken from Class, Sequence,
and Use Case Diagrams describing both the static structure and dynamic behavior of a system.

Communication diagrams show a lot of the same information as sequence diagrams, but because of how the
information is presented, some of it is easier to find in one diagram than the other. Communication
diagrams show which elements each one interacts with better, but sequence diagrams show the order in
which the interactions take place more clearly.

ACTIVITY DIAGRAM:
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency.[1] In the Unified Modeling Language, activity diagrams
can be used to describe the business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control.

Construction
Activity diagrams are constructed from a limited repertoire of shapes, connected with arrows. The most
important shape types:

• rounded rectangles represent activities;

• diamonds represent decisions;

• bars represent the start (split) or end (join) of concurrent activities;

• a black circle represents the start (initial state) of the workflow;

• an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the order in which activities happen.

Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack constructs for
expressing concurrency. However, the join and split symbols in activity diagrams only resolve this for
simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or
loops.

While in UML 1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x, the activity
diagrams were reformalized to be based on Petri net-like semantics, increasing the scope of situations that
can be modeled using activity diagrams. These changes cause many UML 1.x activity diagrams to be
interpreted differently in UML 2.x

PACKAGE DIAGRAM:
A package diagram in the Unified Modeling Language depicts the dependencies between the packages
that make up a model.
Overview
In addition to the standard UML Dependency relationship, there are two special types of
dependencies defined between packages:

• package import

• package merge

A package import is "a relationship between an importing namespace and a package, indicating that the
importing namespace adds the names of the members of the package to its own namespace." [1] By default,
an unlabeled dependency between two packages is interpreted as a package import relationship.

A package merge is "a directed relationship between two packages, that indicates that the contents of the
two packages are to be combined. It is very similar to Generalization in the sense that the source element
conceptually adds the characteristics of the target element to its own characteristics resulting in an element
that combines the characteristics of both"

Usage
• Package diagrams can use packages containing use cases to illustrate the functionality of a
software system.

• Package diagrams can use packages that represent the different layers of a software system to
illustrate the layered architecture of a software system. The dependencies between these packages
can be adorned with labels / stereotypes to indicate the communication mechanism between the
layers.

COMPONENT DIAGRAM:
In the Unified Modeling Language, a component diagram depicts how components are wired together to
form larger components and or software systems. They are used to illustrate the structure of arbitrarily
complex systems.
Components are wired together by using an assembly connector to connect the required interface of one
component with the provided interface of another component. This illustrates the service consumer -
service provider relationship between the two components.

An assembly connector is a "connector between two components that defines that one component provides
the services that another component requires. An assembly connector is a connector that is defined from a
required interface or port to a provided interface or port."A delegation connector is a "connector that links
the external contract of a component (as specified by its ports) to the internal realization of that behavior by
the component’s parts." The example above illustrates what a typical Insurance policy administration
system might look like. Each of the components depicted in the above diagram may have other component
diagrams illustrating their internal structure.