IFS231

Unit 5 class Welcome to IFS231 – 2021

Systems analysis
Orientation for online teaching and learning programme
Agenda
1. Introduction to
systems analysis
2. Introduction to UML Welcome to IFS231 – 2021

3. Databases

Orientation for online teaching and learning programme

Systems analysis
 Unit 5 lecture topics
1. Introduction to systems analysis

2. Introduction to UML

3. Databases
 Where are we?

• What we know so far:

– Requirements and requirements gathering
• Functional and non-functional requirements
• Requirements vs design issues
– Scenarios and scenario identification
• As-Is and To-Be(visionary, evaluation, training)
– Documenting requirements
• BCD, Use-cases, activity diagrams, etc
 Unit objectives

• Describe systems analysis and relate it to the concepts we have learnt so far in this
module.
• Use (a) systems analysis approach(es) to solve business systems problems.
• Identify and describe the building blocks of information systems.
• Elicit and illustrate class diagrams and entity relationship diagrams.
SYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition Whitten Bentley Dittman

Systems Analysis vs. Systems Design

Systems analysis – a problem-solving technique that decomposes a system into
its component pieces for the purpose of studying how well those component parts
work and interact to accomplish their purpose.

Systems design – a complementary problem-solving technique (to systems

analysis) that reassembles a system’s component pieces back into a complete
system—hopefully, an improved system. This may involves adding, deleting, and
changing pieces relative to the original system.

Information systems analysis – those development phases in an information

systems development project the primarily focus on the business problem and
requirements, independent of any technology that can or will be used to
implement a solution to that problem.

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition Whitten Bentley Dittman

Context of Systems Analysis

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition Whitten Bentley Dittman

Repository

Repository – a location (or set of locations) where systems

analysts, systems designers, and system builders keep all of the
documentation associated with one or more systems or projects.

• A network directory of computer-generated files that contain project correspondence,

reports, and data
• A CASE tool dictionary or encyclopedia (Chapter 3)
• Printed documentation (binders and system libraries)
• An intranet website interface to the above components

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition Whitten Bentley Dittman

Model-Driven Analysis Methods

Model-driven analysis – a problem-solving approach that

emphasizes the drawing of pictorial system models to document
and validate both existing and/or proposed systems. Ultimately,
the system model becomes the blueprint for designing and
constructing an improved system.

Model – a representation of either reality or vision. Since “a

picture is worth a thousand words,” most models use pictures to
represent the reality or vision.

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

SYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition Whitten Bentley Dittman

Model-Driven Methods
Structured analysis – a model-driven, process-centered technique used to either analyze
an existing system, define business requirements for a new system, or both. The models
are pictures that illustrate the system’s component pieces: processes and their associated
inputs, outputs, and files.

Information engineering (IE) – a model-driven and data-centered, but process-sensitive

technique for planning, analyzing, and designing information systems. IE models are
pictures that illustrate and synchronize the system’s data and processes.

Object-oriented analysis (OOA) – a model-driven technique that integrates data and

process concerns into constructs called objects. OOA models are pictures that illustrate
the system’s objects from various perspectives such as structure and behavior, and
interactions of the objects.

Object – the encapsulation of the data (called properties) that describes a discrete person,
object, place, event, or thing, with all the processes (called methods) that are allowed to use
or update the data and properties. The only way to access or update the object’s data is to
use the object’s predefined processes.

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

 Unit 5 lecture topics
1. Introduction to systems analysis

2. Introduction to UML

3. Databases
 Introducing UML

• UML= unified modelling language.

• Ref. definition of a model above. Why do we model?
• Unification = standardizing the language of specifying,
visualizing, constructing and documenting the components of
software systems and business models.
• UML mostly uses graphical notations to express the design of
software projects.
• Enabvles ease of collaboration in teams: Communication,
exploration, and validation of design.

Pilone and Pitman, 2005

 Unified Modelling Language (2)

• A UML model is made up of one or more diagrams

• A diagram graphically represents things and the relationships between these
things.
• These things can be representations of real-world objects, software constructs or a
description of the behaviour of some other object.
• Each diagram represents a particular interest or view of the thing being modelled.
• UML 2.0 divides diagrams into structural diagrams and behavioural diagrams .

Pilone and Pitman, 2005

 UML 2.0 – types of diagrams (1)

Structural diagrams Behavioural diagrams

Structural diagrams are used Behavioural diagrams focus

to capture the physical on the behaviour of elements
organisation of the things in in a system. For example, you
your system (how one object can use behavioural diagrams
relates to another. to capture requirements,
operations, and internal state
changes for elements.

Pilone and Pitman, 2005

 UML 2.0 – types of diagrams (2)

Structural diagrams Behavioural diagrams

• Class diagrams • Activity diagrams

• Component diagrams • Communication diagrams
• Composite structure diagrams • Interaction overview diagrams
• Deployment diagrams • Sequence diagrams
• Package diagrams • State machine diagrams
• Object diagrams • Timing diagrams
• Use case diagrams

Pilone and Pitman, 2005

 Overall view of UML Diagrams
Use case diagram Use case diagram

Each use case may

create one activity
diagram

Use case scenario

Use cases and
sequence diagrams
help determine Identifiers
classes Use case scenarios
are generated from Steps
the use case
diagrams
Each use case
Conditions
Collaboration diagram
Class diagram scenario may create
one sequence
diagram
Sequence diagram

Sequence and
collaboration
diagrams are
interchangeable
Statechart diagram

Each class may have

a statechart diagram
to help determine
operations

https://www.conceptdraw.com/helpdesk/how-to-draw-bank-uml-diagram
https://en.wikipedia.org/wiki/File:BankAccount1.svg
https://www.sparxsystems.eu/fileadmin/user_upload/Screenshots/Buch_figures/en/Images/Fig_53_Simple_example_of_a_sequence_diagram.png
https://www.researchgate.net/profile/Durga-Mohapatra-3/publication/220299153/figure/fig3/AS:667587973238791@1536176784476/Statechart-Diagram-of-ATM_W640.jpg
 Overall view of UML Diagrams (2)
1
Statecharts Diagrams Use Cases diagrams
Collaboration diagram
Dynamic modelling, Functional modelling
Dynamic modelling,
focusing on an object.
focusing on spatial
Activities done in each
relationships between
state correspond to
objects
operations

Class Diagrams
Static modelling Sequence Diagrams
System’s structure Dynamic modelling of
scenarios
Objects Diagrams
Static modelling
Context
Activity Diagrams
Dynamic modelling,
focusing on an activity
 Use Case and Class Diagrams

• In this module, we will only cover use case (unit 3) and

class(unit 5) diagrams
• Refer to your notes on Use Case diagrams.
 Class diagrams

• A class represents an object or set of objects that share a common

structure and behavior.
• Using class diagrams, it is easier to
– Define structure of classes
– Define relationship between classes
– Illustrate the structure, entities, behavior, operations, hierarchy of a model
• Class diagrams represent the structure of the system.
• Class diagrams are used
– during requirements analysis to model problem domain concepts
– during system design to model subsystems and interfaces
– during object design to model classes.
 UML Class diagrams: Case
bank
A bank is handling mortgage approvals in a manual and very inefficient
matter. Because of possible changes in the market, the company estimates a
rise by a factor 5 of the number of arriving mortgage requests. There is no
way that the employees can handle all the requests, not even overtime, and
the company cannot employ more people. It is necessary to make the process bank
more efficient. The company has recently invested in a workflow
management system to enable IT implementation of business processes. The
management decides that the mortgage request process should be analysed
and implemented in this system. To be used in the analysis of the current
business practice, the employees have been interviewed about how they Customer
handle a mortgage request from a customer; what activities they perform, in
which sequence they execute the activities, and how they decide what to do
next. The interviews resulted in a heterogeneous view of the practice of
handling mortgage requests.
Mortgage
 Classes

Names
Our main concern for this module
Attributes

Operations, May cause an

object to change state

Responsibilities, Anything
that a class knows or does e.g.
withdraws money, checks
balance
 Class Names

ClassName The name of the class is the only required tag in the graphical representation of a class.
e.g. Appears in the top-most compartment.
Customer

Attributes e.g. An attribute is a named property of a class that describes the object being modeled. In
+ CustomerId: int the class diagram, attributes appear in the second compartment just below the name-
+ Name: Char compartment. Attributes can be:
+ PhoneNumber: String + public
# protected
Operations e.g. - private
+ DepositMoney(): int / derived
+ OpenAccount(): string
+ ClossAccount(): boolean Operations describe the class behavior and appear in the third compartment.
+ ApplyMortgage(): string
--
Software Design (UML)
 Drawing classes

Various configurations. Class name is the only mandatory field

 UML Class Relationships

Relationships

Associations Dependency Generalizations

Dependencies show that a source A generalization can exist between a

element and target element are specific element and a more general
An association how that one model related so that the source element element of the same kind. The
element is linked in some way or makes use of, or depends upon, the specific element inherits the
another model element target element. Changes in the attributes, relationships, and other
behavior or structure of the target characteristics from the general
may mean changes in the source. element.
 Associations
If two classes in a model need to
Student Instructor communicate with each other, there
must be link between them.

An association denotes that link.

Multiplicity of an association is shown

Student Instructor by adding multiplicity adornments to
1..* the line denoting the association.
e.g. a Student has one or more
Instructors

Or
A Student has one or more Instructors
Student Instructor
1..*
 Associations

teaches learns from The behavior of an object in an association

Student Instructor can be show (i.e., the role of an object) using
1..* 1..*
rolenames.

membership Or
Student Memberships
Team
1..* 1..*

member of

1..* 1..* Or
Student Team Dual associations

1 president of 1..*
 Associations
CourseSchedule
Associations can also be objects themselves,
Course called link classes or an association classes.
add(c : Course)
remove(c : Course)

Constraining association relationship is depicted

by navigability of the association. The direction
Router DomainNameServer of the association indicates that the server has
no knowledge of the Router.

next
A class can have a self association.
LinkedListNode
previous
 Associations: Aggregations and associations

An aggregation specifies a whole-part relationship

Engine between an aggregate (a whole) and a constituent part,
Car where the part can exist independently from the
Transmission aggregate. Aggregations are denoted by a hollow-
diamond adornment on the association.

Scrollbar
A composition indicates a strong 1 1
ownership and coincident lifetime of
parts by the whole (i.e., they live and die Window Titlebar
1 1
as a whole). Compositions are denoted
by a filled-diamond adornment on the Menu
association. 1 1 .. *
 Dependencies

CourseSchedule A dependency indicates a semantic

relationship between two or
Course more elements. The dependency from
CourseSchedule to Course exists because
add(c : Course) Course is used in both the add and
remove(c : Course) remove operations of CourseSchedule.
 Generalizations

Person A generalization connects a subclass to its superclass. It denotes an

inheritance of attributes and behavior from the superclass to the subclass
and indicates a specialization in the subclass of the more general superclass.

Student

Student Employee

UML permits a class to inherit from multiple superclasses

TeachingAssistant
Back to our Mortgage Application
 Unit 5 lecture topics
1. Introduction to systems analysis

2. Introduction to UML

3. Databases
 Databases (1)

• Database system provides a framework in which strict procedures and standards are
enforced
• Role of human changes from programming to managing organization’s resources
• Database system enables more sophisticated use of the data
• A database serves many applications by centralizing data and controlling redundant
data
• Data in a database is logically organised by using associations.
• Associations, also known as relationships are used to relate (connect) data between
tables and are needed to retrieve information

34
 Databases (2)

• Data structures created within the database and their relationships determine
effectiveness
• A DBMS eliminates most of file system’s problems
• Current generation stores data structures & relationships between structures &
access paths
• Takes care of defining, storing, managing all access paths and components

Database Systems, 8th Edition 35

 Why databases? Problems with traditional file systems

• Manual system served as a data repository for small data collections

• This was cumbersome for large collections
• Contents of each file folder was logically related
• Initially, computer file systems were an improvement over manual system &
resembled manual systems
• As number of files increased, file systems evolved
– Each file used its own application program to store, retrieve, modify data
– Each file was owned by individual or department that commissioned its creation
• Databases evolved from traditional file systems

Database Systems, 8th Edition 36

 Why databases? Problems with traditional file systems
(cont.)
The following problems with traditional file systems are overcome by databases:
• Files are maintained separately by different functional departments
• This leads to data redundancy (duplicate data in multiple files)
• This also means that there will be data inconsistency (different and conflicting
versions of same data occur at different places),
• And data anomalies (abnormalities when all changes in redundant data are not
made) correctly. These are either Update anomalies, Insertion anomalies or Deletion
anomalies

Laudon & Laudon (2014)

 Why databases? Problems with traditional file systems
(cont.)
• Which also means that there will be a lack of flexibility (changes to existing
structures are difficult)
• There was also a lack of data sharing possibility
• Security features difficult to program - often omitted in file system environments
• Even a simple file system retrieval task required extensive programming
• Could not perform ad hoc queries
• System administration was too complex and difficult

Laudon & Laudon (2014)

 Managing the Database System:
A Shift in Focus

• Databases have become the centre of most information systems

• A database is a shared, integrated computer structure that stores a collection of data
• A database is simply a place to store a group of related objects that are saved in one
file
• Database system consists of logically related data stored in a single logical data
repository
• May be physically distributed among multiple storage facilities

Database Systems, 8th Edition 39

 Relational databases

• A relational database represents data in two-dimensional tables

• Each table stores data about the entity and its attributes.

Relationships Entities / Classes

• are associations between • a general class of people,

instances of one or more places or things for which
entity types that is of interest data is collected, stored and
& represented by lines maintained & represented by
• are given a name, in the form boxes
of an active or a passive • Have
verb, that describes its characteristics/attributes
function. that describe the entity
 Unique identifiers - keys

• Each instance of an entity must have a unique identifier (primary key)

• Uniquely identifying records:

Primary Key Combination Secondary

Foreign keys
primary key Key
• Unique • Combination • Attributes • Attribute not
identifier of two or more used to link used as a
• Examples: attributes tables. primary key
Student ID • Example: • Primary key is • Identifying
number; social Identifying a in one table, records that
security student’s foreign key is share a
number grade for a in another. common value
particular class • Example:
for a particular Major
term
 Relational database - example
Customer_Number First_Name Surname Address 1 Address 2

Customer table
10 Jane Wilson London Road Oxford
Primary 11 John Smith Quai d’Orsay Paris
key 12 Jane Wilson London Road Oxford
13 Desmond Paton Marshall Street Johannesburg
14 Susan Haynes Baker Street London

Foreign key

Order_Number Description Price Colour Customer_Number

100 Swivel chair R89 Black 10

Order table
101 Coat rack R15 Silver 11
102 White board R23 White 12
103 Computer desk R150 Brown 13
104 Filing cabinet R50 Gray 14
TB-42
 Non-relational databases

• Sometimes it is important to use non-relational (noSQL)

databases
• Non-relational databases are a more flexible and more scalable
data model
• Is able to handle large volumes of structured and unstructured
data (web content, graphics, etc).

The answer:
Why socialone
would media involves
want many social
to store different
file types, and the information is not easily
media data in a non-relational database?
organized into tables of columns and rows.
 Database fundamentals (1)

• A database comprises of many objects/entities. An object can be a table, form,

query or report
• A database object has a structure consisting of:
⚫ Field name
⚫ Data type
⚫ FieldDescription
⚫ Properties
⚫ Keys
A table A record/tuple A field/attribute
• consists of data in the • is a set of related fields. • is a characteristic or
form of a grid, that is attribute of an entity
arrayed in rows that is stored in the
(records/tuples) and database. Fields are the
columns specific items of data
(fields)/attributes stored about an entity
e.g. (name, data of
birth, address, etc.).
44
 Database fundamentals (2)
Customer_Number First_Name Surname Address 1 Address 2
10 Jane Wilson London Road Oxford
11 John Smith Quai d’Orsay Paris
12 Jane Wilson London Road Oxford
A record/tuple
13 Desmond Paton Marshall Street Johannesburg
14 Susan Haynes Baker Street London

Customer_Number First_Name Surname Address 1 Address 2

10 Jane Wilson London Road Oxford

11 John Smith Quai d’Orsay Paris
12 Jane Wilson London Road Oxford
13 Desmond Paton Marshall Street Johannesburg

14 Susan Haynes Baker Street London

A field/attribute
45
 Fields (attributes)

• Each field’s accepted values have a data type

• Data types must be declared when the table is defined
• These include:
– Text for words
– Integer for whole numbers
– Double for numbers that have a decimal value
– Currency for numbers that represent rands and cents
– Yes/No for variables that have only two values (e.g. 1/0, on/off, yes/no,
true/false)
– Date/Time for variables that are dates and times

46
Database fundamentals (3)

47
 Entities / Classes

• Each table stores the data about someone or something of

interest to the firm, known as an entity. “Customer” is an
example
• An entity is a tangible person, place, thing or event about
whom or which an organization wants to store data
• Every entity (object) has characteristics, known as attributes
(characteristics) and relationships to other entities
• An entity eventually becomes a table in a database

48
 Database design (1)

• Database design focuses on design of database structure used for end-user data
• A detailed, logical representation of the entities, associations and data elements for
an organization or business
• Used to show associations between entities
• Important when designing complex databases.

Logical • abstract model from business perspective

(conceptual) view • how human views the data

• How database is arranged on direct-access storage

Physical view devices
• How the computer works with the data
49
 Database design (2)

• Design process identifies:

– Relationships among data elements, redundant database elements
– Most efficient way to group data elements to meet business requirements, needs
of application programs
• Normalization
– Streamlining complex groupings of data to minimize redundant data elements
and awkward many-to-many relationships

Well-designed • Facilitates data management

database: • Generates accurate and valuable information
Poorly designed
• Causes difficult-to-trace errors
database: 50
 The Database Management System (DBMS)

• A DBMS is the interface between the user and the database AND between
applications and the physical data files in the database
• DBMS manage structure, control access and enables data to be shared
• Separates the logical view from the physical view of data
• A DBMS includes all the other tools that make it easier to work with (manage) your
data, e.g. a query language, a way of defining structure, methods of indexing the
data for faster access, etc.
• DBMS solves problems caused by traditional file environment
• Reduces redundancy, eliminates inconsistency, uncouples programs and data,
enables organisations to centrally manage data and data security

51
 Advantages of the DBMS

Improved data sharing

Improved data security
Better data integration
Minimized data inconsistency
Improved data access
Improved decision making
Increased end-user productivity
Database Systems, 8th Edition 52
 Disadvantages of DBMS

• Disadvantages of database systems:

Increased costs

Management complexity

Remaining current and updated

Vendor dependence

Frequent upgrade/replacement cycles

Database Systems, 8th Edition 53
 Capabilities of DBMS (1)

Data definition • Specifies structure of database content, used to

capability create tables and define characteristics of fields

• Automated or manual file storing definitions of

Data dictionary data elements and their characteristics

• Used to add, change, delete, retrieve data from

Data manipulation database
language • Examples: Structured Query Language (SQL) and
Microsoft Access user tools for generating SQL

Reports • Many DBMS have report generation capabilities

generation for creating polished reports (Crystal Reports)

Lauden & Lauden (2014)

 Capabilities of DBMS (2)

• DBMS creates and manages complex structures

required for data storage
Data storage • Also stores related data entry forms, screen
management definitions, report definitions, etc.
• DBMS stores the database in multiple physical data
files

Performance • activities that make the database perform more

tuning efficiently

Database Systems, 8th Edition

 Capabilities of DBMS (3)

Data • transforms data entered to conform to

transformation required data structures
and • transforms physically retrieved data to
conform to user’s logical expectations
presentation

• creates a security system that enforces

user security and data privacy
Security
• security rules determine which users
management can access the database, which items
can be accessed, etc.
Database Systems, 8th Edition
 Capabilities of DBMS (4)

Multiuser • uses sophisticated algorithms to ensure

access concurrent access does not affect
integrity
control

• provides backup and data recovery to

Backup and ensure data safety and integrity
recovery • recovery management deals with
recovery of database after a failure
management • Critical to preserving database’s integrity
Database Systems, 8th Edition
 Capabilities of DBMS (5)

Database
• Current DBMS accept end-user requests via
communication multiple different network environments
interfaces

• End users generate answers to queries by filling in

Communications screen forms through Web browser
• DBMS automatically publishes predefined reports
accomplished in on a Web site
several ways: • DBMS connects to third-party systems to distribute
information via e-mail

Database Systems, 8th Edition

 End of formal lecture

• Use the steps below to identify entities/classes

 Example
• A company has several departments. Each department has a
supervisor and at least one employee. A supervisor can only
supervise one department at a time. Employees must be
assigned to at least one, but possibly more departments. At
least one employee is assigned to a project, but an employee
may be on vacation and not assigned to any projects. The
important data fields are the names of the departments,
projects, supervisors and employees, as well as the supervisor
and employee number and a unique project number.
 Step 1. Identify classes
• A class is anything real or abstract about which we want to store data.
• class types fall into five classes: roles, events, locations, tangible things, or
concepts.
• The best way to identify classes is to ask the system owners and users to
identify things about which they would like to capture, store and produce
information. Another source for identifying classes is to study the forms,
files, and reports generated by the current system.
• E.g. a student registration form would refer to Student (a role), but also
Course (an event), Instructor (a role), Advisor (a role), Room (a location),
etc.
 Following the Steps
1. Identify Classes

The classes for this system are :

• Department
• Employee
• Supervisor
• Project
 Step 2. Find Relationships
• There are natural associations between pairs of classes. Listing the
classes down the left column and across the top of a table, we can
form a relationship matrix by filling in an active verb at the
intersection of two classes which are related.
• Each row and column should have at least one relationship listed or
else the class associated with that row or column does not interact
with the rest of the system. In this case, you should question
whether it makes sense to include that class in the system. .
• A student is enrolled in one or more courses
subject verb object
 Following the Steps
• 2. Find Relationships
We construct the following Matrix:

Department Employee Supervisor Project

Department is assigned run by
Employee belongs to works on
Supervisor runs
Project uses
 Step 3. Draw Rough Class Diagram
• Using rectangles for classes and lines for relationships, we can
draw an Class Diagram.
 Step 4. Fill in multiplicity
• At each end of each connector joining rectangles, we need to place a
symbol indicating the minimum and maximum number of instances of the
adjacent rectangle there are for one instance of the rectangle at the other
end of the relationship line.
• The placement of these numbers is often confusing. The first symbol is
either 0 to indicate that it is possible for no instances of the class joining
the connector to be related to a given instance of the class on the other
side of the relationship, 1 if at least one instance is necessary or it is
omitted if more than one instance is required.
• For example, more than one student must be enrolled in a course for it to
run, but it is possible for no students to have a particular instructor (if they
are on leave).
 Step 4. Fill in multiplicity
• The second symbol gives the maximum number of instances of the
class joining the connector for each instance of the class on the
other side of the relationship. If there is only one such instance,
this symbol is 1. If more than 1, the symbol is a crows foot opening
towards the rectangle.
• If you read it like a sentence, the first class is the subject, the
relationship is the verb, the cardinality after the relationship tells
how many direct objects (second class) there are.
• I.e. A student is enrolled in one or more courses
subject verb objects
 Following the Steps
• 4. Fill in multiplicity

From the description of the problem we see that:

• Each department has exactly one supervisor.
• A supervisor is in charge of one and only one department.
• Each department is assigned at least one employee.
• Each employee works for at least one department.
• Each project has at least one employee working on it.
• An employee is assigned to 0 or more projects.
Step 5 : Resolve many-to-many relationships
Step 5 : Resolve many-to-many relationships

• We will create a bridge/composite class between Department and Employee

• We will create a bridge/composite class between Employee and Project
 Step 6. Define Primary Keys
• For each class we must find a unique primary key so that instances
of that class can be distinguished from one another.
• Often a single field or property is a primary key (e.g. a Student ID).
• Other times the identifier is a set of fields or attributes (e.g. a
course needs a department identifier, a course number, and often a
section number; a Room needs a Building Name and a Room
Number).
• When the class is written with all its attributes, the primary key is
underlined or PK is written next to it.
 Step 6. Identify Primary keys and other attributes
for those classes
• Identify or construct a primary for each class, you can use one
of the following indicators:

_no
_id
_code
_num
_number
 Step 6. Primary keys for our example
• Identify or create a primary key for each class, you can use one
of the following indicators:

• The important data fields are the names of the departments,

projects, supervisors and employees, as well as the supervisor
and employee number and a unique project number.
 Following the Steps
• 6. Define Primary Keys
CLASS PRIMARY KEY

Department Department Name

Supervisor Supervisor Number

Employee Employee Number

Project Project Number

 Step 6. Draw Key-Based Class Diagram
• Looking at the Rough Draft Class Diagram, we may see some
relationships which are non-specific or many-to-many.
• Such relationships spell trouble later when we try to
implement the related classes as data stores or data files, since
each record will need an indefinite number of fields to
maintain the many-to-many relationship.
• Fortunately, by introducing an extra class, called an Bridge for
each many-to-many relationship, we can solve this problem.
 Step 6. Draw Key-Based Class diagram
• The new bridge name will be the hyphenation of the names of the two
originating classes. It will have a concatenated key consisting of the keys of
these two classes.
• It will have a 1-1 relationship with each of its parent classes and each
parent will have the same relationship with the associative class that they
had with each other before we introduced the associative class.
• The original relationship between the parents will be deleted from the
diagram.
• The key-based Class Diagram has no many-to-many relationships and each
class has its primary and foreign keys listed below the class name in its
rectangle.
 Following the Steps
• 6. Draw Key-Based Class Diagram
There are two many-to-many relationships in the rough Class Diagram
above, between Department and Employee and between Employee and
Project. Thus we need the bridges Department-Employee and Employee-
Project. The primary key for Department-Employee is the concatenated key
Department Name and Employee Number. The primary key for Employee-
Project is the concatenated key Employee Number and Project Number.
 Step 6. Identify other Attributes
• A data attribute is a characteristic common to all or most
instances of a particular class.
• In this step we try to identify and name all the attributes
essential to the system we are studying without trying to
match them to particular classes.
• The best way to do this is to study the forms, files and reports
currently kept by the users of the system and circle each data
item on the paper copy.
 Step 6. Identify Attributes
• Cross out those which will not be transferred to the new
system, extraneous items such as signatures, and constant
information which is the same for all instances of the form (e.g.
your company name and address).
• The remaining circled items should represent the attributes
you need.
• You should always verify these with your system users.
(Sometimes forms or reports are out of date.)
 Step 7. Map Attributes
• For each attribute we need to match it with exactly one class.
• Often it seems like an attribute should go with more than one class
(e.g. Name).
• In this case you need to add a modifier to the attribute name to
make it unique (e.g. Customer Name, Employee Name, etc.) or
determine which class an attribute "best' describes.
• If you have attributes left over without corresponding classes, you
may have missed a class and its corresponding relationships.
• Identify these missed classes and add them to the relationship
matrix now.
 Following the Steps
• 7. Map Attributes
Attribute class
Department Name Department

Employee Employee
Number
Supervisor Supervisor
Number
Project Project
Number
 Step 8. Draw Fully-Attributed Class Diagram
• If you introduced new classes and attributes in step 5, you
need to redraw the Class diagram.
• When you do so, try to rearrange it so no lines cross by putting
the classes with the most relationships in the middle.
Complete Fully-Attributed Class
Diagram
 Step 9. Check Results
• Look at your diagram from the point of view of a system owner
or user.
• Is everything clear?
• Check through the Multiplicity pairs. Also, look over the list of
attributes associated with each class to see if anything has
been omitted.
 Videos

• https://www.youtube.com/watch?v=FR4QIeZaPeM
• https://www.youtube.com/watch?v=NvrpuBAMddw
• https://www.youtube.com/watch?v=eXiCza050ug
• Access: https://www.youtube.com/watch?v=PBhftKTmdHI (4
parts)