INDEX

 REQUIREMENT ANALYSIS
 INTRODUCTION
 USE CASE DIAGRAM
 Activity Diagram
 CLASS DIAGRAM
 SEQUENCE DIAGRAM
 STATE CHART DIAGRAM
 COLLABORATION DIAGRAM
 DEPLOYEMENT DIAGRAM
 COMPONENT DIAGRAM
 REFERENCECONCLUSION
 INTRODUCTION:
Classifier/Recommender systems are software tools and techniques providing
suggestions for items to be of use to a user. The term item here is generic. It may
represent many concepts. For instance, recommender systems may recommend
news on a news portal, or products in an online shop, or even services. The
recommendations are usually tailored to a given type of user or a given type of user
group. Since recommendations are personalized, they may vary from one user to
another or from one user group to another. If you have ever been on the Amazon
web page (and we hope you have) browsing, or trying to buy an item, you have
probably seen recommender systems at work. In fact, on the Amazon web page the
section “people who purchased this item also purchased...” is the list of items
Amazon’s recommender systems predicted you might be interested in. There are
plenty of other web sites where you can watch recommender system at work. Some
examples are Google news, the yahoo portal, Pandora, Spotify, Netflix, and so on.

The system is broken down into three key areas which help it achieve its goal:

The Content Analyser classifies content using both explicit and implicit attributes.
Explicit attributes are those which define concrete facts about a programme, such as
actors, directors etc. Implicit attributes are more difficult to define, such as how
much action a programme contains, for example. These implicit attributes are
assigned values through unique statistical analysis of the entertainment content.

The User Profiler aims to develop a detailed profile of a user’s needs and preference
in terms of entertainment content attributes. For example, it would not only learn
that a user like comedies it would take this further to understand what type of
comedy they like e.g. Black Comedy, or how much action they like in a programme.
These attributes are obtained by asking a number of specially designed questions at
registration and applying statistical techniques to their answers. A user profile can
also be developed over time by rating programmes which the user has liked and
disliked.

The Recommender is the final aspect of the system and uses the attributes
developed in the analyser and profiler to match a person’s needs and interests, with
content which they will find most interesting and entertaining.
USE CASE DIAGRAM
A use case diagram at its simplest is a representation of a
user's interaction with the system that shows the relationship
between the user and the different use cases in which the user
is involved. A use case diagram can identify the different types
of users of a system and the different use cases and will often
be accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every
possibility, a use-case diagram can help provide a higher-level
view of the system. It has been said before that "Use case
diagrams are the blueprints for your system".[1] They provide
the simplified and graphical representation of what the system
must actually do.

Due to their simplistic nature, use case diagrams can be a good

communication tool for stakeholders. The drawings attempt to
mimic the real world and provide a view for the stakeholder to
understand how the system is going to be designed. Siau and
Lee conducted research to determine if there was a valid
situation for use case diagrams at all or if they were
unnecessary. What was found was that the use case diagrams
conveyed the intent of the system in a more simplified manner
to stakeholders and that they were "interpreted more
completely than class diagrams".[2]

The purpose of the use case diagrams is simply to provide the

high-level view of the system and convey the requirements in
layman's terms for the stakeholders. Additional diagrams and
documentation can be used to provide a complete functional
and technical view of the system.
USE CASE DIAGRAM
Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise
activities and actions[1] with support for choice, iteration and
concurrency. In the Unified Modelling Language, activity diagrams are
intended to model both computational and organizational processes (i.e.
workflows). Activity diagrams show the overall flow of control.

Activity diagrams are constructed from a limited number of shapes,

connected with arrows.[4] The most important shape types:

 rounded rectangles represent actions;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial node) of the workflow;
 an encircled black circle represents the end (final node).

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

Activity diagrams may be regarded as a form of flowchart. Typical

flowchart techniques lack constructs for expressing
concurrency.[5]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,[6] in UML 2.x, the activity diagrams were renormalized to be
based on Petri net-like semantics, increasing the scope of situations that
can be modelled using activity diagrams. These changes cause many
UML 1.x activity diagrams to be interpreted differently in UML 2.x.
UML activity diagrams in version 2.x can be used in various domains,
e.g. in design of embedded systems. It is possible to verify such a
specification using model checking technique.
Activity Diagram
CLASS DIAGRAM
In software engineering, 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 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.[1] The classes in
a class diagram represent both the main elements, interactions
in the application, and the classes to be programmed.
In the diagram, classes are represented with boxes that contain
three compartments:

 The top compartment contains the name of the class. It is

printed in bold and cantered, 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.
 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, many 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 many
subclasses.
CLASS DIAGRAM
SEQUENCE DIAGRAM
A sequence diagram is an interaction diagram that
shows how objects operate with one another and in
what order. It is a construct of a message sequence
chart.
A sequence diagram shows object interactions
arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of
messages exchanged between the objects needed to
carry out the functionality of the scenario. Sequence
diagrams are typically associated with use case
realizations in the Logical View of the system under
development. Sequence diagrams are sometimes
called event diagrams or event scenarios.
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.
SEQUENCE DIAGRAM
STATE CHART DIAGRAM

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.
State chart diagram is one of the five UML diagrams used to model
the dynamic nature of a system. They define different states of an
object during its lifetime and these states are changed by events.
State chart diagrams are useful to model the reactive systems.
Reactive systems can be defined as a system that responds to
external or internal events.
State chart diagram describes the flow of control from one state to
another state. States are defined as a condition in which an object
exists and it changes when some event is triggered. The most
important purpose of State chart diagram is to model lifetime of an
object from creation to termination.
However, the main purpose is to model the reactive system.
Following are the main purposes of using State chart diagrams −
To model the dynamic aspect of a system.
To model the life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model the states of an object.
STATE CHART DIAGRAM
COLLABORATION DIAGRAM
A collaboration diagram, also called a communication
diagram or interaction diagram, is an illustration of the
relationships and interactions among software objects
in the Unified Modelling Language (UML). The concept
is more than a decade old although it has been refined
as modelling paradigms have evolved.

A collaboration diagram resembles a flowchart that

portrays the roles, functionality and behaviour of
individual objects as well as the overall operation of
the system in real time. Objects are shown as
rectangles with naming labels inside. These labels are
preceded by colons and may be underlined. The
relationships between the objects are shown as lines
connecting the rectangles. The messages between
objects are shown as arrows connecting the relevant
rectangles along with labels that define the message
sequencing.

Collaboration diagrams are best suited to the portrayal

of simple interactions among relatively small numbers
of objects. As the number of objects and messages
grows, a collaboration diagram can become difficult to
read. Several vendors offer software for creating and
editing collaboration diagrams.
COLLABORATION DIAGRAM
DEPLOYEMENT DIAGRAM
A deployment diagram in the Unified Modelling
Language models the physical deployment
of artefacts on nodes. To describe a web site, for example,
a deployment diagram would show what hardware
components ("nodes") exist (e.g., a web server, an
application server, and a database server), what software
components ("artefacts") run on each node (e.g., web
application, database), and how the different pieces are
connected (e.g. JDBC, REST, RMI).
The nodes appear as boxes, and the artefacts allocated to
each node appear as rectangles within the boxes. Nodes
may have sub nodes, which appear as nested boxes. A
single node in a deployment diagram may conceptually
represent multiple physical nodes, such as a cluster of
database servers.

There are two types of Nodes:

Device Node
Execution Environment Node
Device nodes are physical computing resources with
processing memory and services to execute software,
such as typical computers or mobile phones. An execution
environment node (EEN) is a software computing resource
that runs within an outer node and which itself provides a
service to host and execute other executable software
elements.
DEPLOYEMENT DIAGRAM
COMPONENT DIAGRAM

Component diagrams are different in terms of nature

and behaviour. Component diagrams are used to model
the physical aspects of a system. Now the question is,
what are these physical aspects? Physical aspects are
the elements such as executables, libraries, files,
documents, etc. which reside in a node.
Component diagrams are used to visualize the
organization and relationships among components in a
system. These diagrams are also used to make
executable systems.
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.
Thus from that point of view, component diagrams are
used to visualize the physical components in a system.
These components are libraries, packages, files, etc.
Component diagrams can also be described as a static
implementation view of a system. Static
implementation represents the organization of the
components at a moment.
A single component diagram cannot represent the
entire system but a collection of diagrams is used to
represent the whole.
COMPONENT DIAGRAM
Online Diagram Software to draw Flowcharts, UML & more
Classifier/Recommender systems are software tools and
techniques providing suggestions for items to be of use to
a user. The term item here is generic. It may represent
many concepts. For instance, recommender systems may
recommend news on a news portal, or products in an
online shop, or even services. The recommendations are
usually tailored to a given type of user or a given type of
user group. Since recommendations are personalized,
they may vary from one user to another or from one user
group to another. If you have ever been on the Amazon
web page (and we hope you have) browsing, or trying to
buy an item, you have probably seen recommender
systems at work. In fact, on the Amazon web page the
section “people who purchased this item also
purchased...” is the list of items Amazon’s recommender
systems predicted you might be interested in. There are
plenty of other web sites where you can watch
recommender system at work. Some examples are Google
news, the yahoo portal, Pandora, Spotify, Netflix, and so
on.