|
1)
External
Entities
v
We
look out for people, things or devices that lie
outside the scope of the software system. These
external entities may produce information from the
software system. The software system may also need
to retain information or knowledge about the external
entity. Information here includes both data and
control types. Examples of external entities include
nouns and noun phrases like user , homeowner , keyboards,
sensors , remote database systems etc.
2)
Things
or Occurrences Remembered
v
We
look for items of information and events that must
be observed and recorded by the system. Examples
of occurrences include eg peripherals interrupts/events,
signals or even the registration of a vehicle.
3)
Roles
played
v
We
consider the role or roles played by people or system
being analyzed. Basically, there are three types
of roles to be considered.
v
The
first type constitutes those representing users
of the system (e.g. clerk, receptionist who interacts
with the system).
v
The
second are those representing people who do not
interact directly with the system but whose information
is remembered by the system (e.g. employee, vehicle
owners, customer etc).
v
The
third role type encompasses people who interact
with the system and have information retained by
the system. (e.g. managers using email on a personalized
management system or a lab technician maintaining
an inventory system that keep records of authorized
lab stuff).
v
Roles
are considered outside the scope of the system if
no information of the associated person needs to
be recorded by the system,
v
The
potential classes identified using this category
are considered to lie within the broader scope of
the problem domain under consideration.
4)
Sites
v
We
consider the location, place or environment etc.
that the system being analyzed needs knowledge of.
Examples will include a vehicle guidance system
for an industrial robot which might need information
on the physical layout of a factory floor, an electronic
warfare system which need topological information
of the physical environment in which it operates
etc.
5)
Organization
Unit
v
We
have to ask ourselves what department, division
, organization etc. does the system need to keep
information about? If the system needs to remember
information about such an organizational unit and/or
provide processing of it, then the organizational
unit is considered as a potential class.
v
For
example, if a system needs to keep track of information
about a sales department (e.g. department’s name,
number of stuff, inventory list, gross list, gross
list, gross , operating cost etc.) and / or provide
processing in the form of computation of annual
tax returns, generating stock levels reports etc.
6)
Structures
v
Structures
help us to find potential classes. Also it help
us to derive more information from the list of potential
classes we have obtained earlier using the previous
5 categories. The additional information that we
are talking about here will help us to identify
the constituents of some classes (classes and attributes),
and the location of potential groupings of subclasses
into classes and super classes and so on.
| 
