System Development Techniques Individual Assignment - Computer Science
Read instructions very carefully!
15th of August - DEADLINE
DIT SDT ... file will have all instructions
ITTMS/.DS_Store
__MACOSX/ITTMS/._.DS_Store
ITTMS/.classpath
ITTMS/.project
SDT
org.eclipse.jdt.core.javabuilder
org.eclipse.jdt.core.javanature
ITTMS/.settings/org.eclipse.jdt.core.prefs
eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=13
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=13
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.problem.enablePreviewFeatures=disabled
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.eclipse.jdt.core.compiler.problem.reportPreviewFeatures=warning
org.eclipse.jdt.core.compiler.release=enabled
org.eclipse.jdt.core.compiler.source=13
ITTMS/src/ITTMS.java
ITTMS/src/ITTMS.java
import
Domain
.
*
;
public
class
ITTMS
{
public
static
void
main
(
String
[]
args
)
{
// TODO Auto-generated method stub
new
Domain
.
ITTMS
().
run
();
}
}
ITTMS/src/General/Helper.java
ITTMS/src/General/Helper.java
package
General
;
import
java
.
util
.
InputMismatchException
;
import
java
.
util
.
Scanner
;
public
class
Helper
{
public
static
void
printBlankLines
(
int
n
)
{
for
(
int
i
=
0
;
i
<
n
;
i
++
)
{
System
.
out
.
println
();
}
}
public
static
String
getString
(
String
message
)
{
Scanner
in
=
new
Scanner
(
System
.
in
);
System
.
out
.
print
(
message
);
String
input
=
in
.
nextLine
();
return
input
;
}
public
static
int
getInt
(
String
message
)
{
Scanner
in
=
new
Scanner
(
System
.
in
);
int
input
=
0
;
try
{
// implement exception handling if user enter non integer value
System
.
out
.
print
(
message
);
input
=
in
.
nextInt
();
}
catch
(
InputMismatchException
e
)
{
System
.
out
.
println
(
Please enter an integer !
);
in
=
new
Scanner
(
System
.
in
);
}
return
input
;
}
public
static
int
getInt
(
String
message
,
int
min
,
int
max
)
{
int
input
=
0
;
while
(
true
)
{
input
=
getInt
(
message
);
if
(
input
<
min
||
input
>
max
)
{
System
.
out
.
println
(
Input should be between
+
min
+
and
+
max
);
}
else
{
break
;
}
}
return
input
;
}
public
static
int
getChoice
(
int
max
)
{
Scanner
in
=
new
Scanner
(
System
.
in
);
System
.
out
.
print
(
Please enter ( 1 -
+
max
+
) >
);
int
choice
=
0
;
while
(
true
)
{
try
{
// implement exception handling if user enter non integer value
choice
=
in
.
nextInt
();
if
(
!
(
choice
<=
0
||
choice
>
max
))
{
break
;
}
else
{
throw
new
InputMismatchException
();
}
}
catch
(
InputMismatchException
e
)
{
System
.
out
.
println
(
Please enter an integer ( 1 -
+
max
+
) !
);
System
.
out
.
print
(
Please enter again >
);
in
=
new
Scanner
(
System
.
in
);
}
}
return
choice
;
}
}
ITTMS/src/DAO/AdministratorDAO.java
ITTMS/src/DAO/AdministratorDAO.java
package
DAO
;
import
Model
.
Administrator
;
public
class
AdministratorDAO
{
public
Administrator
getAdministrator
()
{
//fake admin
Administrator
admin
=
new
Administrator
(
password
);
return
admin
;
}
}
ITTMS/src/DAO/SkillDAO.java
ITTMS/src/DAO/SkillDAO.java
package
DAO
;
import
java
.
util
.
*
;
import
Model
.
Skill
;
public
class
SkillDAO
{
private
ArrayList
<
Skill
>
skills
;
public
SkillDAO
()
{
//fake skills database data
skills
=
new
ArrayList
<
Skill
>
();
//public Skill(int skillID,String name, int level) {
Skill
skill1
=
new
Skill
(
1
,
Java 2 Enterprise Edition
,
1
);
Skill
skill2
=
new
Skill
(
2
,
Java 2 Enterprise Edition
,
2
);
Skill
skill3
=
new
Skill
(
3
,
C# .Net
,
1
);
Skill
skill4
=
new
Skill
(
4
,
C# .Net
,
2
);
Skill
skill5
=
new
Skill
(
5
,
Oracle database administration
,
1
);
Skill
skill6
=
new
Skill
(
6
,
Oracle database administration
,
2
);
Skill
skill7
=
new
Skill
(
7
,
MySQL database administration
,
1
);
Skill
skill8
=
new
Skill
(
8
,
MySQL database administration
,
2
);
Skill
skill9
=
new
Skill
(
9
,
Azure cloud administration
,
1
);
Skill
skill10
=
new
Skill
(
10
,
Azure cloud administration
,
2
);
Skill
skill11
=
new
Skill
(
11
,
AWS cloud administration
,
1
);
Skill
skill12
=
new
Skill
(
12
,
AWS cloud administration
,
2
);
skills
.
add
(
skill1
);
skills
.
add
(
skill2
);
skills
.
add
(
skill3
);
skills
.
add
(
skill4
);
skills
.
add
(
skill5
);
skills
.
add
(
skill6
);
skills
.
add
(
skill7
);
skills
.
add
(
skill8
);
skills
.
add
(
skill9
);
skills
.
add
(
skill10
);
skills
.
add
(
skill11
);
skills
.
add
(
skill12
);
}
public
void
removeSkillByID
(
int
id
)
{
Skill
skill
=
getSkillByID
(
id
);
skills
.
remove
(
skill
);
}
public
void
addSkill
(
String
name
,
int
level
)
{
int
nextSkillID
=
getNextSkillID
();
Skill
newSkill
=
new
Skill
(
nextSkillID
,
name
,
level
);
skills
.
add
(
newSkill
);
}
public
int
getNextSkillID
()
{
int
id
=
0
;
for
(
Skill
s
:
skills
)
{
if
(
s
.
getSkillID
()
>
id
)
{
id
=
s
.
getSkillID
();
}
}
return
id
+
1
;
}
public
ArrayList
<
Skill
>
getSkills
()
{
return
skills
;
}
public
Skill
getSkillByID
(
int
id
)
{
Skill
skill
=
null
;
for
(
Skill
s
:
skills
)
{
if
(
s
.
getSkillID
()
==
id
)
{
skill
=
s
;
break
;
}
}
return
skill
;
}
public
boolean
isSkillIDValid
(
int
skillID
)
{
boolean
isFound
=
false
;
for
(
Skill
s
:
skills
)
{
if
(
s
.
getSkillID
()
==
skillID
)
{
isFound
=
true
;
break
;
}
}
return
isFound
;
}
public
Skill
getSkillByNameAndLevel
(
String
skillName
,
int
level
)
{
Skill
skill
=
null
;
for
(
Skill
s
:
skills
)
{
if
(
s
.
getName
().
equals
(
skillName
)
&&
s
.
getLevel
()
==
level
)
{
skill
=
s
;
break
;
}
}
return
skill
;
}
}
ITTMS/src/DAO/StaffDAO.java
ITTMS/src/DAO/StaffDAO.java
package
DAO
;
import
java
.
util
.
*
;
import
Domain
.
ITTMS
;
import
Model
.
StaffSkill
;
import
Model
.
Staff
;
public
class
StaffDAO
{
private
ArrayList
<
Staff
>
staffs
;
private
SkillDAO
skills
;
public
StaffDAO
(){
//fake staff database data
staffs
=
new
ArrayList
<
Staff
>
();
skills
=
ITTMS
.
getSkillDAO
();
Staff
s1
=
new
Staff
(
1
,
user1
,
password
,
Staff 1
);
s1
.
addSkill
(
skills
.
getSkillByID
(
1
));
s1
.
addSkill
(
skills
.
getSkillByID
(
3
));
Staff
s2
=
new
Staff
(
2
,
user2
,
password
,
Staff 2
);
s2
.
addSkill
(
skills
.
getSkillByID
(
2
));
s2
.
addSkill
(
skills
.
getSkillByID
(
4
));
Staff
s3
=
new
Staff
(
3
,
user3
,
password
,
Staff 3
);
s3
.
addSkill
(
skills
.
getSkillByID
(
5
));
s3
.
addSkill
(
skills
.
getSkillByID
(
6
));
staffs
.
add
(
s1
);
staffs
.
add
(
s2
);
staffs
.
add
(
s3
);
}
public
Staff
getStaffByUserName
(
String
username
)
{
Staff
staff
=
null
;
for
(
Staff
s
:
staffs
)
{
if
(
s
.
getUsername
().
equals
(
username
))
{
staff
=
s
;
break
;
}
}
return
staff
;
}
public
boolean
isValidStaffID
(
int
staffID
)
{
boolean
isValid
=
true
;
if
(
getStaffByID
(
staffID
)
==
null
)
{
isValid
=
false
;
}
return
isValid
;
}
public
Staff
getStaffByID
(
int
staffID
)
{
Staff
staff
=
null
;
for
(
Staff
s
:
staffs
)
{
if
(
s
.
getStaffID
()
==
staffID
)
{
staff
=
s
;
break
;
}
}
return
staff
;
}
public
ArrayList
<
Staff
>
getStaffList
(){
return
staffs
;
}
}
ITTMS/src/Model/Skill.java
ITTMS/src/Model/Skill.java
package
Model
;
public
class
Skill
{
private
int
skillID
;
private
String
name
;
private
int
level
;
public
Skill
(
int
skillID
,
String
name
,
int
level
)
{
this
.
skillID
=
skillID
;
this
.
name
=
name
;
this
.
level
=
level
;
}
public
int
getSkillID
()
{
return
skillID
;
}
public
String
getName
()
{
return
name
;
}
public
int
getLevel
()
{
return
level
;
}
public
void
display
()
{
System
.
out
.
println
(
Skill ID:
+
skillID
+
Name:
+
name
+
Level:
+
level
);
}
}
ITTMS/src/Model/StaffSkill.java
ITTMS/src/Model/StaffSkill.java
package
Model
;
import
java
.
util
.
*
;
public
class
StaffSkill
{
private
int
staffID
;
private
ArrayList
<
Skill
>
skills
;
public
StaffSkill
(
int
staffID
)
{
this
.
staffID
=
staffID
;
this
.
skills
=
new
ArrayList
<
Skill
>
();
}
public
ArrayList
<
Skill
>
getSkills
()
{
return
skills
;
}
public
void
addSkill
(
Skill
skill
)
{
this
.
skills
.
add
(
skill
);
}
public
int
getStaffID
()
{
return
staffID
;
}
public
void
display
()
{
for
(
Skill
r
:
skills
)
{
r
.
display
();
}
}
public
boolean
isSkillInStaff
(
String
skillName
)
{
boolean
skillInStaff
=
false
;
for
(
Skill
r
:
skills
)
{
if
(
r
.
getName
().
equals
(
skillName
))
{
skillInStaff
=
true
;
break
;
}
}
return
skillInStaff
;
}
public
void
removeSkillByName
(
String
skillName
){
for
(
Skill
skill
:
skills
)
{
if
(
skill
.
getName
().
equals
(
skillName
))
{
skills
.
remove
(
skill
);
break
;
}
}
}
public
void
removeSkillByID
(
int
skillIDToRemove
){
for
(
Skill
skill
:
skills
)
{
if
(
skill
.
getSkillID
()
==
skillIDToRemove
)
{
skills
.
remove
(
skill
);
break
;
}
}
}
}
ITTMS/src/Model/User.java
ITTMS/src/Model/User.java
package
Model
;
public
class
User
{
private
String
username
;
private
String
password
;
public
User
(
String
username
,
String
password
)
{
this
.
username
=
username
;
this
.
password
=
password
;
}
public
String
getUsername
()
{
return
username
;
}
public
boolean
authenticateUser
(
String
password
)
{
//Suppose to use SHA algorithm here,
//use clear password for simplification
boolean
status
=
false
;
if
(
this
.
password
.
equals
(
password
))
{
status
=
true
;
}
return
status
;
}
}
ITTMS/src/Model/Administrator.java
ITTMS/src/Model/Administrator.java
package
Model
;
public
class
Administrator
extends
User
{
public
Administrator
(
Diploma in Information Technology
System Development Techniques
Instruction for CA3 Individual Assignment
July 2021 Semester
Continual Assessment 3 Individual Assignment (40\%)
Task:
1. Discuss the software development and systems analysis and design
2. Explain the systems development life cycle
3. Explain the iterative development
4. Discuss the systems requirements
5. Discuss the information-gathering techniques
6. Explain the documenting workflows with activity diagrams
7. Explain:
a. Use cases and user goals
b. Use cases and event decomposition
c. Use cases and CRUD
d. Use cases diagrams
8. Draw use cases using StarUML
a. UML diagramming
b. Use case diagram
c. Use case description
9. Understand conceptual model
10. Discuss class, association focusing on generalisation, composition and
aggregation
11. Describe the extending requirements models
12. Explain the use case descriptions
13. Discuss the system sequence diagram
14. Describe the integrating requirements models
15. Describe design system inputs and outputs
16. Draw use cases using StarUML
a. Class diagram
b. Sequence diagram
17. Discuss the inputs and outputs for system design
18. Explain system architecture
19. Discuss the SDLC methodologies, models, tools and techniques
20. Discuss the difference approaches to software construction and modelling
21. Explain Agile development
22. Discuss on the bridging from analysis to implementation
23. Explain object-oriented architectural design
24. Explain the object-oriented detailed design
25. Explain the design with communication diagrams
26. Describe the MVC design pattern
27. Explain use case realisation with sequence diagrams
28. Design object-oriented and use case realisation
This assignment will make use of what you have learnt in:
1. Systems Requirements
2. Use Cases
3. Introduction to CASE tool – StarUML
4. Domain Modelling
5. Extending Requirements Models
6. Essentials of Systems Design
7. Approaches to System Development
8. Object-Oriented Design
9. Advanced Systems Design Concepts
10. Use Case Realisations
Case Study:
Part 1: Current System Analysis and Design (50 marks)
“While Singapore’s digital push began long before the COVID-19 pandemic, the
past year has propelled us into a new digital normal. To support the rapid growth
of the country’s digital ecosystem, a ready pool of talent is needed to drive new
frontiers. Accordingly, in recent months, the Infocomm Media Development
Authority (IMDA) has introduced various initiatives to attract, train and develop a
strong pipeline of tech professionals along with its industry partners.”
Source: https://www.imda.gov.sg/news-and-events/impact-news/2021/04/Paving-
Singapores-digital-future-with-a-career-in-tech
To support the above initiative by IMDA, Gov Tech Singapore
(https://www.tech.gov.sg/) has decided to roll out a IT Talent Management System
(ITTMS) for companies to manage their staffs IT skills.
This system allows each company ITTMS administrator to manage all the staff’s IT
skills records in the company.
User Stories:
• As a ITTMS administrator, I can perform CRUD on IT skill records so that I
can update the latest skills information requirements.
• As a ITTMS administrator, I can assign or remove staff skill record, so that the
staff skill records are up to date.
• As a staff, I can view my IT skills listing, so that I can know my current IT
competency.
Note: CRUD is Create. Read, Update and Delete (CRUD) operations.
There will be one administrator for this system, that is ITTMS administrator.
Both administrator and staffs need to login to the system to use ITTMS.
All data are stored in a database (e.g. MySQL)
The current critical IT skills identified are:
• Java 2 Enterprise Edition
• C# .Net
• Oracle database administration
• MySQL database administration
• Azure cloud administration
• AWS cloud administration
https://www.imda.gov.sg/news-and-events/impact-news/2021/04/Paving-Singapores-digital-future-with-a-career-in-tech
https://www.imda.gov.sg/news-and-events/impact-news/2021/04/Paving-Singapores-digital-future-with-a-career-in-tech
https://www.tech.gov.sg/
You as the System Analyst at Gov Tech Singapore has been assigned to design the
ITTMS. A first cut of ITTMS has been developed in Java for testing.
You are to develop and submit the following UML documents based on the User
Stories and implemented Java codes:
a. Use case diagram and description (10 marks)
b. Class diagram (10 marks)
c. Sequence diagram (20 marks)
d. Package diagram (10 marks)
Part 2: System Enhancement (50 marks)
Propose two more Use cases that are useful for this system.
Explain why the two Use cases are useful for this system
Submit the following documents for each proposed Use case
a. Explanation of the usefulness of this Use Case (2 marks x2)
b. User Stories (3 marks x2)
c. Use case diagram and description (5 marks x 2)
d. Class diagram (5 marks x 2)
e. Sequence diagram (5 marks x 2)
f. Implemented Java codes (5 marks x 2)
Report format
1. The report should have a cover page, content page, introduction, write-up on the
task, conclusion, references and appendices
2. The cover page should include:
i. Institution name (and institution logo) the programme
ii. Module name, semester and year
iii. Date of submission
iv. Student’s name and student ID numbers
3. Each question should be a separate section
4. The references should be presented in Harvard format and should have at least
THREE (3) references.
Report Word Limit
2000 to 2500 words
Report Font and Spacing
Font: Calibri, black coloured
Font size: 12 and 1 ½ or double spacing.
Penalty Marks for Late Submission
By one day: 20\% to be deducted from total marks.
More than one day: submission will NOT be graded.
Plagiarism and Collusion
The submitted report must show evidence that this is students’ own work. No marks
will be awarded if there are no workings or reasonable explanations. Please be
reminded that plagiarism and collusion is a serious offence, and all cases will be
referred to the administration. Grades will be withheld if the submission is suspected
for plagiarism or collusion till investigations are completed.
Important Deadlines
CA3 Written Report Deadline: 16th Aug 2021, 11.59 a.m. Submit the softcopy of
your report via D2L/eGlobal.
Marking Rubic
The marking rubic for this written report can be found in the appendix of this
assignment.
Lecturer Contact
You should contact your lecturer via your SIM email whenever you have any issue
about your project. You may send your email to: [email protected]
Marking Guide
Part 1
Marking rubric for Use Case diagram and description
Excellent Very good Good Acceptable Weak
Use cases are
included. Both
the use case
diagram and
description are
present. The
use cases
accurately
represent the
main functions
of the system
including the
appropriate
actors. Use
cases are
clear and easy
to understand
with very few
syntactic
errors
(diagramming
errors).
Use cases are
included. Both
the use case
diagram and
the description
are present.
The use cases
represent
most of the
system
functionality
with only a few
missing
pieces. The
use have a
few minor
logical
problems
contributing to
some small
lack of
understanding.
The use cases
contain a few
syntactic
errors
(diagramming
errors) but
these do not
cause any lack
of clarity for
the reader.
Use cases are
included, but
the textual
description is
missing or
does not
accurately
describe the
use case.
Some use
cases are
missing. The
use cases are
generally
unclear. The
use cases
contain many
diagramming
errors that
slow down the
reader.
Use cases are
included, but
many core
functions are
missing from
the use cases.
The textual
descriptions
are missing or
do not add
understanding
or clarity to the
use case.
Overall the
use cases
confuse more
than they help.
The use cases
contain many
diagramming
errors that
cause them to
be extremely
hard to
understand.
No use cases
present.
Marking rubric for Class Diagram
Excellent Very good Acceptable Weak
Class diagram
uses UML
correctly to depict
the classes in the
right format. All
classes that are
needed are
present, and the
level of detail is
acceptable. Class
diagram is missing
some obvious
classes that
should be present.
Class diagram
doesnt correctly
depict
relationships
among classes.
(Missing
cardinality,
inheritance, etc…)
Class diagram is
missing many
required classes,
relationships or
cardinalities. Class
diagram very
poorly reflects the
rest of the design
Class diagram
uses UML
correctly to depict
the classes in the
right format. All
classes that are
needed are
present, and the
level of detail is
acceptable. Class
diagram is missing
some obvious
classes that
should be present.
Class diagram
doesnt correctly
depict
relationships
among classes.
(Missing
cardinality,
inheritance, etc…)
Class diagram is
missing many
required classes,
relationships or
cardinalities. Class
diagram very
poorly reflects the
rest of the design
Class diagram
uses UML
correctly to depict
the classes in the
right format. All
classes that are
needed are
present, and the
level of detail is
acceptable. Class
diagram is missing
some obvious
classes that
should be present.
Class diagram
doesnt correctly
depict
relationships
among classes.
(Missing
cardinality,
inheritance, etc…)
Class diagram is
missing many
required classes,
relationships or
cardinalities. Class
diagram very
poorly reflects the
rest of the design
No Class diagram
presented
Sequence diagram
Excellent Very good Acceptable Weak
Sequence diagram
is correct, has
appropriate arrows
which are
horizontal.
Correctly depicts
scenario.
Sequence diagram
depicts the
scenario but has
some invalid UML
syntax.
Sequence diagram
is unclear, or does
not correctly reflect
the scenario.
Diagram does not
follow UML.
No Sequence
diagram
presented.
Package diagram
Excellent Very good Acceptable Weak
Package diagram
is correct, has
appropriate arrows
which are
horizontal.
Correctly depicts
scenario.
Package diagram
depicts the
scenario but has
some invalid UML
syntax.
Package diagram
is unclear or does
not correctly reflect
the scenario.
Diagram does not
follow UML.
No Package
diagram
presented.
Part 2
Explanation of the usefulness of each Use Case
Excellent Very good Good Acceptable Weak
Proposed
Enhancement
is very useful
to the
business
requirements.
Proposed
Enhancement
is useful to the
business
requirements.
Proposed
Enhancement
is somewhat
useful to the
business
requirements.
Proposed
Enhancement
is not useful to
the business
requirements.
No
enhancement
presented
Use case diagram and description, Class diagram, Sequence diagram are the same
as Part 1
Implemented Java codes
Excellent Very good Good Acceptable Weak
Implemented
Java codes is
fully functional
as according
to the
proposal.
Implemented
Java codes
follows the
given MVC
framework
Implemented
Java codes is
partially
functional with
no error as
according to
the proposal.
Implemented
Java codes
follows the
given MVC
framework
Implemented
Java codes is
functional with
run time errors
Implemented
Java codes
follows the
given MVC
framework
Implemented
Java codes
did not follows
the given MVC
framework
No
Implemented
Java codes
presented
System Development Techniques
Diploma in Information Technology
Lesson 9
Revision
• What is meant by Agile Development and
iterative development?
• What is the purpose of a System Vision
Document?
Revision
• What are the benefits of doing vendor
research during information-gathering
activities?
• Explain why the Unified Modeling Language
(UML) is important to use as a standard for
creating information systems models.
Revision
• The current employee leave application process
works as follow:
• The Employee fills in the leave application form
online with the following details.
– Start Date of leave
– End Date of leave
– Type of leave: Annual/Parental/Study
Revision
• The employee submits the leave application form to
the Leaves Application System (LAS).
• The LAS check if the employee has sufficient leaves
balance and there are no crashes of non-leave block
period.
• (Non-leave block period is start and end dates where
the employee is not supposed to take leaves.)
Revision
• If there are crashes, the LAS sends a not approved
notice to the employee.
• If there are no crashes, the LAS sends the leave
application to the manager.
• The manager can choose to approve or not approve
the employee’s leave application.
– If the manager does not approve, the LAS sends a not
approved notice to the employee.
– If the manager approves, the LAS sends an approved
notice to the employee.
Revision
• Based the case study process flow, document
the workflow by drawing the Activity
Diagrams.
Revision
• Below is the User Stories for employee leave
application process in the previous question.
– As an employee, I want to apply leaves so that I can go on leaves.
– As an employee, I want to check my leaves balance so that I know how
much days of leaves I have left.
– As an employee, I want to check my leaves application status so that I
know if my leave application has been approved.
– As a manager I want to check new employee leaves application so that
I can process those new leaves application
– As a manager, I want to check which employees has how much leaves
left.
Revision
• Draw the use case diagram based on the
above user stories.
• One of the use cases in the case study is
“Apply Leaves”. Write the use case description
for “Apply Leaves”.
• Design the domain class “Leaves Application
Details”.
Revision
• The statuses of a Leave Application Detail works as
follow:
– When the leave is first submitted the status is “Waiting for
Processing”
– If the LAS found that there are crashes, the status changed
to “Crashes found” and the process ends.
– If the LAS found that there are no crashes, the status
changed to “Waiting for Manager Processing”.
– If the Manager approval, the status changed to “Approved”
and the process ends.
– If the Manager does not approval, the status changed to
“Not Approved” and the process ends.
System Development Techniques
Diploma in Information Technology
Lesson 20
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Discuss the trends in technology
infrastructure
• Discuss the trends in application platform
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 1: Automation strategy rethink
– As digital business scales up, demands on I&O automation
will increase, which will threaten the viability of this type
of approach.
– By 2025, more than 90\% of enterprises will have an
automation architect, up from less than 20\% today.
– Ensure automation is scalable to digital business needs,
addressing use cases that align with business strategy
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 2: Hybrid IT vs. disaster recovery confidence
– Hybrid IT combines on-site data centers with cloud
technologies.
– Hybrid IT blends cloud architecture flavors—public,
private, hybrid—with in-house data centers in order to
deliver data workloads, apps, and services across the
hybrid infrastructure environments.
– This hybrid model allows organizations to manage and
govern IT services in a standard way, with a focus
on adopting cloud computing as a strategic imperative
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 2: Hybrid IT vs. disaster recovery confidence
– Hybrid infrastructures make disaster recovery increasingly
complex. In the new world of distributed applications and
complex integration, I&O professionals are facing the
uncomfortable truth that if a disaster strikes, heritage
recovery strategies may not address the full extent of their
operating scenarios.
– Rethink disaster recovery strategies to account for
workloads in public and private clouds, in traditional data
centers and at the edge.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 3: Scaling DevOps agility
– An increasing number of enterprise product teams work in
DevOps environments.
– https://en.wikipedia.org/wiki/DevOps
• a set of practices that combines software
development (Dev) and IT operations (Ops).
• aims to shorten the systems development life cycle and
provide continuous delivery with high software quality.
• complementary with Agile software development;
several DevOps aspects came from the Agile
methodology.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 3: Scaling DevOps agility
– Ensure the skills needed are available at scale and that
many teams do not end up duplicating effort in similar
ways.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 4: Infrastructure is everywhere — so is your
data
– In a hybrid IT world, IT infrastructure is located wherever
the business needs it, meaning that data is located
everywhere, too. By 2022, more than 50\% of enterprise
data will be created and processed outside the data center
or cloud, up from less than 10\% in 2019.
– I&O leaders must plan for the accompanying data impacts.
As data is increasingly distributed, I&O teams can struggle
to provide the protection and management needed.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 5: Overwhelming impact of IoT
– Due to the transformative and far-reaching nature of IoT
projects and their inherent complexity, understanding
which team is responsible for each piece of the IoT puzzle
can be a challenge.
– “I&O must become involved early on in IoT planning
discussions to understand the proposed service and
support model at scale,” says Winser. “This will avoid the
cascade effect of unforeseen service gaps that could cause
serious headaches in the future. I&O leaders have
important thought leadership to offer IoT teams regarding
service and support considerations.”
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 6: Distributed cloud
– As businesses continue to move to the cloud, a shift is
occurring — the cloud is now coming to them.
– This is known as distributed cloud, in which public cloud
services will be available in different physical locations
while the provider remains responsible for the operation,
governance, updates and evolution of the services.
– The distributed model is likely to appeal to organizations
that have been constrained by the physical location of
cloud services in the past.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 7: Immersive experience
– Today’s I&O customers have higher expectations than ever,
influenced heavily by their experience of consumer
technology provided by digital giants. Functions once
considered value-adds are now baseline expectations.
Users expect seamless integration, immediate feedback
and very high levels of availability.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 8: Democratization of IT
– Low-code and no-code platforms enable users to
quickly build applications using minimal code
approaches. This can enable “citizen
development” intended to save time and
resources.
– E.g. SAP configurable module. Plug in AI module
for game development.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 9: Networking — what’s next?
– Automation will be key for enabling networks that are
simpler, more reliable and responsive to change.
– Starlink
• https://www.starlink.com/
• A satellite internet constellation being constructed
by SpaceX providing satellite Internet access.The
constellation will consist of thousands of mass-
produced small satellites in low Earth orbit (LEO),
working in combination with ground transceivers.
Gartner Top 10 Trends Impacting
Infrastructure & Operations for 2020
• Trend 10: Hybrid digital infrastructure management
– I&O leaders must seek tools that challenge silos of
visibility, and some vendors are already trying to solve
these issues.
– I&O leaders must carefully evaluate promised functionality
and anticipate that their own teams may be forced to fill
gaps by integrating tools and growing (not replacing) their
baseline.
Read
Gartner
• https://www.gartner.com/smarterwithgartner/gartner-top-
10-trends-impacting-infrastructure-operations-for-2020/
Deloitte Insights:
• https://www2.deloitte.com/content/dam/Deloitte/pt/Docu
ments/tech-trends/TechTrends2020.pdf
System Development Techniques
Diploma in Information Technology
Lesson 12
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Discuss the SDLC methodologies, models,
tools and techniques
• Explain Agile development
Methodologies, Models, Tools, and
Techniques
• System development Methodology
– provides guidelines for every aspect of the system
development life cycle.
• For example, within a methodology, certain models, such as
diagrams, are used to describe and specify the requirements.
– Related to these models are the techniques for how the
project team will do its work.
• Examples of technique
– The guidelines for conducting a user interview.
– How to write user story
– How to identify use cases/domain class etc.
Methodologies, Models, Tools, and
Techniques
• System development Methodology
– Each project team will use a set of tools to
• build models,
• record information, and
• write the code.
– These tools are considered part of the overall
methodology used for a given project.
• techniques, models, and tools
support one another to provide
a comprehensive, integrated
methodology.
Methodologies, Models, Tools, and
Techniques
• System development Methodology
– methodologies used in a company can be
• developed by systems professionals within the company based on their
experience.
• learned and used based on purchased materials and training from
consulting firms or vendors. (e.g. IBM Rational)
– methodology a company adopts can be
• informal, ad hoc and almost undefined
• can very chaotic
– Management in IT departments should adopt a flexible
methodology so it can be adapted to different types of
projects and systems.
Methodologies, Models, Tools, and
Techniques
• Models
– to record or communicate information,
– a representation of an important aspect of the real world.
– Aka abstraction
• separate out an aspect that is of particular importance .
• For example, a map, only shows the important aspect of a
geographical features. Details like building colours, number of
trees along the roads are left out.
Methodologies, Models, Tools, and
Techniques
• Models used in system development
– representations of inputs, outputs, processes, data,
objects, object interactions, locations, networks, and
devices, among other things.
– Mostly graphical models
• drawn representations that employ agreed-upon
symbols and conventions in the form of diagrams and
charts
• The Unified Modelling Language
Methodologies, Models, Tools, and
Techniques
• Models used in system development
– Some models of system components
• Use case diagram
• Domain model class diagram Design class diagram
• Sequence diagram
• Package diagram
• Screen design template
• Dialog design storyboard
• Entity-relationship diagram (ERD)
• Database schema
Methodologies, Models, Tools, and
Techniques
• Models used in system development
– Project-planning model,
– Some models used to manage the development
process
• Gantt chart
• Organizational hierarchy chart
• Financial analysis models—NPV, payback period
• System development life-cycle model
• Stakeholders list
• Iteration plan
Methodologies, Models, Tools, and
Techniques
• Tools
– software support that helps create models or
other components required in the project.
– UML Tools:
• IBM Rational
• StarUML
– A project management software tool,
• Microsoft Project
Methodologies, Models, Tools, and
Techniques
• Techniques
– a collection of guidelines that helps an analyst complete an
activity or task.
– it often includes step-by-step instructions for creating a
model, or it might include more general advice on
collecting information from system users.
– Examples include data-modeling techniques, software-
testing techniques, user-interviewing techniques, and
relational database design techniques.
Agile Development
• Highly volatile marketplace
– forced businesses to respond rapidly to new
opportunities.
– Sometimes opportunities appear in the middle of
implementing another business initiative.
– To survive, businesses must be agile—
• able to change directions rapidly, even in the middle of
a project.
Agile Development
• Agile development
– is a philosophy and set of guidelines for
developing information systems in an unknown,
rapidly changing environment,
– complements adaptive approaches to the SDLC
and methodologies that support it.
– emphasis on taking an adaptive approach and
making it agile in all development activities and
tasks.
Agile Development
• Agile modelling
– is a philosophy about how to build models,
• some of which are formal and detailed,
• others sketchy and minimal.
– All the models you have learned how to create can
be used with Agile modelling.
Agile Development
• Agile Development Philosophy and Values
– “Manifesto for Agile Software Development”
• four basic values or core philosophy
1. Value responding to change over following a plan
2. Value individuals and interactions over processes and
tools
3. Value working software over comprehensive
documentation
4. Value customer collaboration over contract
negotiation
Agile Development
• Chaordic
– Some industry leaders in the Agile movement coined the
term “chaordic to describe an Agile project.
– Comes from two words: chaos and order.
• software projects always have unpredictable
elements—hence, a certain amount of chaos.
• developers need to accept a certain amount of chaos
and mix that with other Agile modeling and
development techniques that help to provide order and
structure to the project.
Agile Development
• Another important aspect of Agile
development
– customers must continually be involved with the
project team.
– become part of the technical team.
– working software is being developed throughout
the project, customers are continually involved in
defining requirements and testing components.
Agile Development
• Agile Modelling Principles:
– not about doing less modelling,
– but about doing the right kind of modelling at the right
level of detail for the right purposes.
– doesn’t dictate which models to build or how formal to
make those models.
– helps developers stay on track with their models by using
them as a means to an end rather than end deliverables.
– express the attitude that developers should have as they
develop software.
Agile Development
• Agile Modelling Principles:
– Develop Software as Your Primary Goal
– Enable the Next Effort as Your Secondary Goal
– Minimize Your Modeling Activity—Few and Simple
– Embrace Change and Change Incrementally
– Model with a Purpose
– Build Multiple Models
Agile Development
• Agile Modelling Principles:
– Build Multiple Models
• Build High-Quality Models and Get Feedback Rapidly
• Focus on Content Rather Than Representation
• Learn from Each Other with Open Communication
• Know Your Models and How to Use Them
• Adapt to Specific Project Needs
– Maximize Stakeholder ROI
Summary
• A methodology includes
– a collection of techniques that are used to
complete activities within each phase or iteration
of the system development life cycle.
– The activities include the completion of a variety
of models as well as other documents and
deliverables.
– system developers use software tools to help
them complete their activities.
Summary
• Agile development
– is a philosophy and set of guidelines for
developing information systems in an unknown,
rapidly changing environment,
– complements adaptive approaches to the SDLC
and methodologies that support it.
– emphasis on taking an adaptive approach and
making it agile in all development activities and
tasks.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 10
System Development Techniques
Diploma in Information Technology
Lesson 16
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Describe implementation activities
• Describe various types of software tests (unit,
integration, usability, and performance and stress)
• Explain how and why each software test is used
Implementation and deployment
Testing
• Testing activities
– process of examining a component, subsystem, or system
to determine its operational characteristics and whether it
contains any defects.
– developers must have well-defined specifications for both
functional and non-functional requirements.
– test developers develop precise definitions of expected
operational characteristics based on the requirements
specifications. (e.g. use case descriptions, activity
diagrams)
Testing
• Testing activities
– The developers test software by designing and building the
software, exercising its function, and examining the
results.
– If the results indicate a shortcoming or defect, then the
project team cycles back through earlier implementation
or deployment activities until the shortcoming is remedied
or the defect is eliminated.
Test type
• Four type of testing for different phase.
– During Implementation
• Unit Testing
• Integration Testing
– During Deployment
• System testing
• User acceptance testing (UAT)
Test type
• During Implementation
– Unit Testing
• Software components must perform to the defined
requirements and specifications when tested in
isolation
• for example, a component that incorrectly calculates
sales tax amounts in different locations is unacceptable.
Test type
• During Implementation
– Integration testing
• Software components that perform correctly in
isolation must also perform correctly when executed in
combination with other components.
• They must communicate correctly with other
components in the system.
• For example a sales tax component that calculates
incorrectly when receiving money amounts in foreign
currencies is unacceptable .
Test type
• During Deployment
– System testing
• A system or subsystem must meet both functional and
non-functional requirements.
• For example an item lookup function in a Sales
subsystems retrieves data within 2 seconds when
running in isolation, but requires 30 seconds when
running within the complete system with a live
database.
Test type
• During Deployment
– User acceptance testing (UAT)
• Software must not only operate correctly, but must also
satisfy the business need and meet all user “ease of
use” and “completeness” requirements.
• for example, a commission system that fails to handle
special promotions or a data-entry function with a
poorly designed sequence of forms is unacceptable.
Test case
• A test case is a formal description:
– A starting state or condition
– One or more events to which the software must
respond
– The expected response or ending state
Test data
• Test data
– Represented by the starting and ending states and the
events.
– For example,
• the starting state of a system may represent a particular set of
data.
– such as the existence of a particular customer and order for that
customer.
• The event may be represented by a set of input data items.
– such as a customer account number and order number used to query
order status.
• The expected response (ending) may be a described behavior.
– such as the display of certain information, or a specific state of stored
data, such as a canceled order.
Unit Testing
• Unit testing
– lowest level testing for a new software system.
– In object-oriented development approaches, a unit can be
defined as
• an individual method or
• a class or
• a small set of closely integrated classes such as a package.
– primary purpose is to test a small piece of the code in
isolation to make sure that it functions correctly before it is
integrated into a larger program.
– make sure that the unit is error-free before being
integrated into the larger program.
Unit Testing
• Three primary characteristics of a unit test:
– done in isolation.
– test data and the test are done by the programmer who
wrote the code.
– It is done quickly without a large requirement for other
resources.
Unit Testing
• Unit test of a component often depends on others
unit.
– either to receive a parameter or to output a result.
– Example below:
• Blue is the unit to be tested
• Green is the input or output units.
Unit Testing
• Unit test would need a driver and a stub to be
written and used to test the unit.
• In this example, the stubs are overlapped to indicate
that a single stub class could be used to receive all
unit test results.
Unit Testing
• Programmers should use automated tools (e.g. JUnit) to write
unit tests codes.
• Unit test data should include both good and bad test data.
• Unit testing should enhance the programmer’s productivity,
not consume a lot of resources.
• In an iterative development project where the philosophy is
that the system is developed organically, software methods or
classes can be written, unit tested, and quickly integrated into
the new system as it gradually “grows.”
Integration Testing
• Integration testing
– to test the interfaces between these units and to
test the entire integrated piece of software.
– evaluates the functional behavior of a group of
classes or components when they are combined
together.
Integration Testing
• Two types of results that can be tested.
– test the interface itself between the components.
• Interface incompatibility.
– For example, one method passes a parameter of the wrong data type
to another method.
• Parameter values
– A method is passed or returns a value that was unexpected, such as a
negative number for a price.
• Unexpected state interactions
– The states of two or more objects interact to cause complex failures,
Example bubble tea order object state is “collected” and is passed to
on to a Place Order process.
– tested is the value of the expected result.
Integration Testing
• Integration testing activities
– Building the component for integration test.
• Write driver and stub for integration testing.
• Use automated tools
– Creating test data.
• Integration test data is more complex and usually requires
coordination between programmers.
• Responsibility for coordinating the creation, formatting, recording,
use, and updating of the test data must be assigned.
Integration Testing
• Integration testing activities
– Conducting the integration test.
• Decisions must be made and assignments given about who will
conduct the integration tests, how they are done, what resources
are used, and how frequently they are executed.
– Evaluating the results.
• Often this requires involvement by all the programmers.
– Logging test results.
• An error log is usually kept at this point to ensure that errors are
tracked and corrected.
Integration Testing
• Integration testing activities
– Correcting the code and retesting.
• Programmer makes the corrections, conducts any required unit
tests, and submits the components back for integration testing.
• The person conducting the integration test usually attempts to
identify and isolate the cause of the error as much as possible.
System testing
• System test
– a comprehensive integration test of the behaviour of an
entire system or independent subsystem.
– performed at the end of each iteration where software is
completed.
– to verify the functional and non-functional requirements,
• Business functions
• Response time
• Stability
• Resources usage
• Throughput
• Speed
System testing
• Type of System test
– Build and smoke
– Performance test (stress test)
• Response time
• Throughput
System testing
• Build and smoke test
– is a system test that is typically performed daily or
several times per week.
– The system is completely compiled and linked
(built), and a list of tests is executed to see
whether anything malfunctions in an obvious way
(“smokes”).
System testing
• Build and smoke test
– provide rapid feedback on significant integration problems.
– Any problem that occurs during a build and smoke test
must result from software modified or added since the
previous test.
– Daily testing ensures that errors are found quickly and that
they can be easily tracked to their sources.
– Less-frequent testing provides rapidly diminishing benefits
because more software has changed and errors are more
difficult to track to their sources.
System testing
• A performance test, (stress test)
– determines whether a system or subsystem can meet such
time-based performance criteria as response time or
throughput.
– Response time requirements
• specify desired or maximum allowable time limits for software
responses to queries and updates.
– Throughput requirements
• specify the desired or minimum number of queries and
transactions that must be processed per minute or hour.
System testing
• Performance tests
– are complex because they can involve
• multiple programs,
• subsystems,
• computer systems, and
• network infrastructure.
– require a large suite of test data to simulate
system operation under normal or maximum load.
User Acceptance Testing (UAT)
• User acceptance test (UAT)
– is comprehensive system testing to determine whether the
system fulfills user requirements and can support all
business and user scenarios.
– normally the final stage in testing the system.
– Although the primary focus is usually on the functional
requirements, the non- functional requirements are often
also verified.
User Acceptance Testing (UAT)
• User acceptance test (UAT)
– In some cases, UAT is a formal milestone, and requires
completion and sign-off by the client.
– Details of acceptance tests may even be included in a
request for proposal (RFP) and procurement contract when
a new system is built by or purchased from an external
party.
– Payments to the developers are often tied to passing
specific acceptance tests.
User Acceptance Testing (UAT)
• User acceptance test (UAT)
– All too often, because the project is behind and the
delivery date is fast approaching, UAT is minimized or
partially skipped.
– However, minimizing the UAT is always a mistake and a
source of problems and disagreements.
– It is the UAT that verifies that the system is ready to be
deployed.
– If the UAT is minimized or skipped, then it is almost a
certainty that the deployed system will have major
problems.
User Acceptance Testing (UAT)
• Planning the UAT
– should be included in the total project plan,
• included in specific iterations or have its own iterations toward the
end of the project.
– Detailed plans for the UAT itself need to be developed
early.
– Waiting until late in the project to plan the UAT causes
serious difficulties and delays.
– test functional and nonfunctional requirements. .
User Acceptance Testing (UAT)
• Planning the UAT
– Test cases should be identified to test various business
events, including
• external events (from the users),
• temporal events (such as month-end and year-end processing and
reporting), and
• state events (such as inventory order points triggered).
– The test plan include test cases to verify the fulfillment of
the specification.
User Acceptance Testing (UAT)
• Planning the UAT
– Use user stories and use cases descriptions as inputs to
develop UAT test cases.
– Developing the details of what is to be included in the UAT
occurs throughout the project.
– The UAT test plan begins early and continues throughout
the project.
– As each requirement is specified, the following question
should be asked: “How can the UAT test that this
specification is complete?”
User Acceptance Testing (UAT)
• Preparation and Pre-UAT Activities
Simple UAT test case list
User Acceptance Testing (UAT)
• Preparation and Pre-UAT Activities
– UAT test data
• Two primary types of test data:
– data entered by users and
– internal data residing in the database.
• The test data entered by users can be
– precisely defined and documented.
» verification of expected results is easier.
– create ad hoc data based on the requirement to be tested
User Acceptance Testing (UAT)
• Management and Execution of the UAT
– decide who will participate and who has responsibility for
the UAT.
– Ideally system users have primary responsibility.
• take full responsibility for identifying test cases,
• creating test data, and
• carrying out the UAT.
– Unfortunately, in many organizations, the users either are not
prepared, do not have enough expertise, or do not have time from
their regular responsibilities to take over the testing completely.
– it is common that some project personnel are required to help plan,
organize, and execute the tests on behalf of system users.
User Acceptance Testing (UAT)
• Management and Execution of the UAT
– both users and development personnel are part of the
team.
– Specific tests need to be scheduled.
– Test data needs to be ready and in place.
– Specific users will have assignments to complete their
tasks.
– At the conclusion of each test, the results must be verified.
If there are failures, the required fixes must be
documented and tracked.
– The test case tracking list must be kept to track errors (if
any)
User Acceptance Testing (UAT)
• Management and Execution of the UAT
– Test case tracking list
Summary
• Four type of testing for different phase.
– During Implementation
• Unit Testing
– Software components must perform to the defined
requirements and specifications when tested in isolation
• Integration Testing
– Software components that perform correctly in isolation must
also perform correctly when executed in combination with
other components.
Summary
• Four type of testing for different phase.
– During Deployment
• System testing
– A system or subsystem must meet both functional and non-
functional requirements.
• User acceptance testing (UAT)
– Software must not only operate correctly, but must also
satisfy the business need and meet all user “ease of use” and
“completeness” requirements.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 14
System Development Techniques
Diploma in Information Technology
Lesson 2
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Discuss the systems requirements
• Discuss the information-gathering techniques
• Explain the documenting workflows with
activity diagrams
Systems Analysis Activities
• Third core process,
– discover and understand the details.
– aka systems analysis.
Systems Analysis Activities
• The activities are as follows:
– Gather detailed information.
– Define requirements.
– Prioritize requirements.
– Develop user-interface dialogs.
– Evaluate requirements with users.
• By completing these activities, the analyst defines in great
detail what the information system needs to accomplish to
provide the organization with the desired benefits.
Gather Detailed Information
• Systems analysts (SA) obtain information from people by
– interviewing or
– watching them work.
• Obtain additional information by
– reviewing planning documents and policy statements
– study existing systems, including their documentation
– looking at what other companies (particularly
vendors) have done when faced with a similar
business need.
Gather Detailed Information
– try to understand an existing system by identifying
and understanding activities of all the current and
future users
• SA must become an expert in that business
area.
– For example, to implement a loan-processing system, the SA needs to
become an expert on the rules used for approving credit.
• The most successful SA become experts in their
organization’s main business.
Define Requirements
• Uses gathered information to define
requirements for the new system.
• System requirements include
– functions the system must perform (functional
requirements) and such related issues
– user-interface formats
– requirements for reliability, performance, and
security (non functional requirements).
Define Requirements
• Creates models to record requirements.
– Example of models: use case diagrams, activity
diagrams, and domain model class diagrams.
• Reviews the models with users
• Refines and expands the models to reflect
new or updated information.
Prioritize Requirements
• Establish which requirements are most crucial for the
system.
• Sometimes, users request additional system
functions that are desirable but not essential.
• Need to ask which functions are truly important and
which are fairly important but not absolutely
required.
• Resources are always limited, it is important to know
what is absolutely required.
Prioritize Requirements
• Scope Creep: System requirements tend to expand as
users make more suggestions
• Requirements priorities help to determine the
number, composition, and ordering of project
iterations.
• High-priority requirements are often incorporated
into early project iterations so analysts and users
have ample opportunity to refine those parts of the
system.
Develop User-Interface Dialogs
• User evaluating a user interface is an easy and
simpler way to get feedback and gather information
because the user can see and feel the system.
• To most users, the user interface is all that matters.
• Developing user-interface dialogs (wireframe) is a
powerful method to document requirements.
Develop User-Interface Dialogs
• SA can
– develop user interfaces via abstract models, such
as interaction diagrams and written dialogs, or
– Develop storyboards or user-interface prototypes
on the actual input/output devices that users will
use (e.g., a computer monitor, iPad, or
smartphone).
Develop User-Interface Dialogs
• A prototype interface can serve as a requirement and
a starting point for developing a portion of the
system.
• A user-interface prototype developed in an early
iteration can be expanded in later iterations to
become a fully functioning part of the system.
Evaluate Requirements with Users
• SA usually use an iterative process to get user input
to model requirements, return to the user for
additional input or validation/feedback, and then
incorporate the new inputs and refine the models.
• The processes of getting requirements, building
models and prototypes, and evaluating them with
users may repeat many times until requirements
models and prototypes are complete and accurate.
System Requirements
• System requirements
– all the activities the new system must perform or
support and the constraints that the new system
must meet.
• Two categories:
– functional and non-functional requirements.
Functional requirements
• Activities that the system must perform (i.e., the
business uses to which the system will be applied).
• For example, a payroll system, the required business
uses might include such functions as
– “generate electronic fund transfers,”
– “calculate commission amounts,”
– “calculate payroll taxes,”
– “maintain employee-dependent information,”,
Non-functional requirements
• Characteristics of the system other than those
activities it must perform or support.
• FURPS
– functional, usability, reliability, performance, and
security.
• Functional: same as functional requirements defined
previously.
FURPS
• Usability requirements
– operational characteristics related to users, such
as the user interface, related work procedures,
online help, and documentation.
• For example, the user interface for a smartphone app
should behave similarly to other apps when responding
to such gestures as two-finger slides, pinching, and
expanding.
• Additional requirements might include menu format,
colour schemes, use of the organization’s logo, and
multilanguage support.
FURPS
• Reliability requirements
– how often a system exhibits such behaviours as
service outages and incorrect processing and how
it detects and recovers from those problems.
FURPS
• Performance requirements
– operational characteristics related to measures of
workload, such as throughput and response time.
– For example, the client portion of a system might
be required to have a 0.5 second response time to
all button presses, and the server might need to
support
FURPS
• Security requirements
– how access to the application will be controlled
and how data will be protected during storage and
transmission.
– For example, the application might be password
protected, encrypt locally stored data with 1024-
bit keys, and use secure HTTP for communication
among client and server nodes.
Stakeholders
• People who have an interest in the successful
implementation of the system.
• For example, accounting system the
stakeholders
– bookkeepers, accountants, managers and
executives, customers, suppliers, auditors,
investors.
Stakeholders
• Each stakeholder group interacts with the system in
different ways,
• Each has a unique perspective on system
requirements.
• Before gathering detailed information, the analyst
identifies every type of stakeholder who has an
interest in the new system and ensures that critical
people from each stakeholder category are available
to serve as the business experts.
Information-Gathering Techniques
• The following are common Information-
Gathering Techniques
• Interviewing users and other stakeholders
• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions
Interviewing users and other
stakeholders
• Effective way to understand business functions and business
rules.
• Most time- consuming and resource-expensive option.
• SA does the following:
– Prepare detailed questions
– Meet with individuals or groups of users
– Obtain and discuss answers to the questions
– Document the answers
– Follow up as needed in future meetings or interviews
• Process may take some time, usually requires multiple
sessions with each of the users or user groups.
Distributing and collecting
questionnaires
• Enable SA to collect information from a large number
of stakeholders.
• Even if the stakeholders are widely distributed
geographically, they can still help define
requirements through questionnaires.
• Used to obtain preliminary insight into stakeholder
information needs, which helps to determine areas
that need further research using other methods.
Reviewing inputs, outputs, and
documentation
• Two sources of documentation. (External and
Internal)
– External to the organization
• industry-wide professional organizations and other
companies.
• may not be easy to obtain information from other
companies,
• may be available in industry journals and magazines
report the findings of “best practices” studies.
Reviewing inputs, outputs, and
documentation
- Internal to the organization
• revieing internal documents and procedures.
• good way to get a preliminary understanding of the
processes.
• serve as visual aids for the interview and as the working
documents for discussion
• helps identify business rules that may not come up in the
interviews.
• helps reveal discrepancies and redundancies in the business
processes.
• However, procedure documents frequently are not kept up
to date, and they commonly include errors. SA should review
them with the users.
Observing and documenting
business procedures
• observing business process in action helps to
understand the current business functions and
fundamental business needs,
• the processes could and often should change to be
made more efficient.
• do not get locked into believing there is only one way
of performing the process.
Researching vendor solutions
• Consulting firms often have experience with the
same problems,
• Software firms may have packaged solutions for a
particular business need.
• Taking advantage of existing knowledge or solutions
can avoid costly mistakes and save time and money.
Collecting active user comments
and suggestions
• Portions of the system are constructed and tested during each
iteration.
• Users and other stakeholders perform the initial testing of
system functions during the iteration in which those functions
are implemented.
• They also test and use those same functions during later
iterations.
• User feedback from initial and later testing is a valuable
source of requirements information
Models
• A model is a representation or abstraction of some aspect of
the system being built.
• There are dozens of different models that an analyst or
designer might develop and use
Documenting Workflows with
Activity Diagrams
• One effective way to capture workflow is with a UML
activity diagram.
• An activity diagram describes the various user (or
system) activities, the person or component that
completes each activity, and the sequential flow of
these activities.
Documenting Workflows with
Activity Diagrams
• Activity diagram basic symbols
Documenting Workflows with
Activity Diagrams
• The flattened ovals represent the individual activities
in a workflow.
• The connecting arrows represent the sequence of
the activities.
• The black circles denote the beginning and the
ending of the workflow.
• The diamond is a decision point at which the flow of
the process will either follow one path or another.
Documenting Workflows with
Activity Diagrams
• The heavy solid line is a synchronization bar, which
either splits the path into multiple concurrent paths
or recombines concurrent paths.
• The swimlane represents an agent who performs the
activities.
– each agent follows a path parallel with other agents in the
workflow, as with swimmers in a swimming pool.
Documenting Workflows
with Activity Diagrams
• Order fulfillment process
Documenting Workflows
with Activity Diagrams
• Processing begins when the
customer has completed the
order checkout process and
the warehouse begins order
fulfillment.
• Omits many error-handling
path- ways, including what
happens if enough item stock
is on hand to fulfill only part of
an order.
Documenting Workflows
with Activity Diagrams
• Ordering a product that
has to be manufactured
to match customer
specifications.
Documenting Workflows
with Activity Diagrams
• To show that the
salesperson sends the
order to Engineering, the
diagram uses a new
symbol to emphasize the
transmission of the
document between Sales
and Engineering.
Documenting Workflows
with Activity Diagrams
• After Engineering
develops the
specifications, two
concurrent activities
happen: Purchasing
orders the materials, and
Production writes the
program for the
automated milling
machines.
Documenting Workflows
with Activity Diagrams
• These two activities are
completely independent
and can occur at the same
time.
• Notice that one
synchronization bar splits
the path into two
concurrent paths and that
another synchronization
bar reconnects them.
Documenting Workflows
with Activity Diagrams
• Finally, Scheduling puts
the order on the
Production schedule.
Summary
• System analysis activities are as follows:
– Gather detailed information.
– Define requirements.
– Prioritize requirements.
– Develop user-interface dialogs.
– Evaluate requirements with users.
Summary
• The following are common Information-
Gathering Techniques
• Interviewing users and other stakeholders
• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions
Summary
• One effective way to capture workflow is with a UML activity
diagram.
• An activity diagram describes the various user (or system)
activities, the person or component that completes each
activity, and the sequential flow of these activities.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 2
System Development Techniques
Diploma in Information Technology
Lesson 1
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Discuss the software development and
systems analysis and design
• Explain the systems development life cycle
• Explain the iterative development
Information System
• Information system
– a set of interrelated components that collect,
process, store, and provide as output the
information needed to complete business tasks.
– consists of software, database, and manual
processes.
Systems analysis
• Activities that to understand and specify what
the new system should accomplish.
• Systems analysis describes in detail what a
system must do to satisfy the need or solve
the problem.
Systems analysis
• Example, a customer management system must:
• track customers,
• register products,
• monitor warranties,
• track service levels,
• And many other functions
all of which have many details.
Systems design
• Activities that enable a person to describe in
detail how the information system will
actually be implemented to provide the
needed solution.
• Describes how the system will actually work.
• Specifies in detail all the components of the
solution system and how they work together.
System analysis vs design
• System analysis
– What is required for the new system to solve the
problem
• System design
– How the system will operate to solve the problem
System analysis vs design
• System analysis
– Example: A customer management system must:
track customers, register products, monitor
warranties, track service levels.
• System design
– Some possible artifacts: UI design, use cases, class
diagrams, activity diagram, ER diagram etc
Systems Analyst
• Programmers don’t just sit down and start
writing program code.
• Need a systems analyst to plan, capturing the
vision, understanding details, specifying
needs—before designing and writing the code
that satisfies the vision.
Systems analysis and design
• Systems analysis and design provides the tools
and techniques required to complete the IS
development process:
1. Understand the need (business need).
2. Capture the vision.
3. Define a solution.
4. Communicate the vision and the solution.
5. Build the solution or direct others in building the solution.
6. Confirm that the solution meets the need.
7. Launch the solution application.
The System Development Life Cycle (SDLC)
• SDLC :
– a framework that identifies all the activities
required to research, build, deploy, and often
maintain an information system.
– includes all activities needed for the planning,
systems analysis, systems design, programming,
testing, and user training stages of information
systems development, as well as other project
management activities that are required to
successfully deploy the new information system.
The System Development Life Cycle (SDLC)
• Six core processes
• Identify the problem or need and obtain approval to
proceed with the project.
• Plan and monitor the project—what to do, how to do it,
and who does it.
• Discover and understand the details of the problem or the
need—what is required?
• Design the system components that solve the problem or
satisfy the need how will it actually work?
• Build, test, and integrate system components
• Complete system tests and then deploy the solution
The System Development Life Cycle (SDLC)
• Six core processes
The System Development Life Cycle (SDLC)
• Many ways to implement the six core
processes of the SDLC to handle each project’s
complexity.
• IS development methodology
– set of comprehensive guidelines for carrying out all the
activities of each core process of the SDLC.
– each methodology prescribes a way of carrying out the
development project,
– every organization develops its own system development
methodology over time to suit its needs.
Agile Development
• IS research efforts have resulted in many new
information systems development
methodologies/processes to improve the
chance of project success.
• These are all based on what is called Agile
development.
Agile Development
• Agile development philosophy
– neither team members nor the users completely
understand the problems and complexities of a new
system,
– the project plan and the execution of the project must be
responsive to unanticipated issues.
– the plan must be agile and flexible.
– It must have procedures in place to allow for, anticipate,
and even embrace changes and new requirements that
come up during the development process.
Agile Development
• The six core processes are still involved in
Agile development, but they are carried out
iteratively.
Iterative Development
• An approach to system development in which the
system is “grown” in an almost organic fashion.
• Core components are developed first and then
additional components are added.
• Iterative: the six core development processes are
repeated for each component.
Iterative Development
• Benefits
– Pieces of the system (subsystem) can sometimes
be deployed sooner. If there are core functions
that provide basic support for users, these can be
deployed in an early iteration.
Iterative Development
• Benefits
– By dividing the system into subsystems, the most
difficult problems can be identified and addressed
early in the project.
– Many of today’s systems are so large and complex
that even with a formal process it is impossible to
remember and understand everything.
– By focusing on a subsystem at a time, the
requirements are fewer and easier to solve.
Iterative Development
• Benefits
– Developing a system in iterations makes the entire
development process more flexible and able to
address new requirements and issues that come
up throughout the project.
Iterative Development
• A key element of iterative development is
dividing system components into pieces that
can be completed in two to four weeks.
• During one iteration, all the core development
processes are involved (programming to
system- wide testing)
• The result is a working part of the system,
even though it may only have a portion of the
functionality that is ultimately required.
Iterative Development
• Developers choose components for each
iteration based on priority, either the
components most needed or riskiest to
implement.
• SDLC : a framework that identifies all the
activities required to research, build, deploy,
and often maintain an information system.
• The six core processes of a SDLC are
• Identify the problem and obtain approval
• Plan and monitor the project
• Discover and understand the details
• Design the system components
• Build, test, and integrate system components
• Complete system tests and then deploy the solution
Summary
Summary
• Many ways to implement the six core
processes of the SDLC to handle each project’s
complexity.
• Agile development is the most common
methodology to implement SDLC.
• The six core processes are still involved in
Agile development, but they are carried out
iteratively.
Summary
• Iterative development is an approach to
system development in which the system is
“grown” in an almost organic fashion.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 1
System Development Techniques
Diploma in Information Technology
Lesson 17
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Describe the deployment activities
• List various approaches to data conversion and
system deployment
• Discuss the advantages and disadvantages of the
approaches
• Describe training and user support requirements for
new and operational systems
Deployment
Deployment Activities
• Deployment activities
– involve many conflicting constraints
• cost,
• need to maintain positive customer relations,
• need to support employees,
• logistical complexity,
• overall risk to the organization.
– main activities
• UAT
• Converting and Initializing Data
• Training Users
• Configuring the Production Environment
Converting and Initializing Data
• Converting and Initializing Data
– An operational system requires a fully populated database
to support ongoing processing.
• For example, online order-entry and management functions rely
on stored information about products, promotions, customers,
and previous orders.
– Developers must ensure that such information is present
in the database at the moment the subsystem becomes
operational.
Converting and Initializing Data
• Converting and Initializing Data
– Data needed at system start-up can be obtained from
these sources:
• Files or databases of a system being replaced
• Manual records
• Files or databases from other systems in the organization
• User feedback during normal system operation
Converting and Initializing Data
• Converting and Initializing Data
– Reusing Existing Databases
• Most new information systems replace or augment an existing
manual or automated system.
• Pluck the old system out and attached the new system into the
existing database.
• In the simplest form, old system’s database is used directly by the
new system with little or no change to the database structure.
• For upgraded systems, some changes to database content are
usually required. Typical changes include adding new tables,
adding new attributes, and modifying existing tables or attributes.
Converting and Initializing Data
• Converting and Initializing Data
– Reloading Databases
• More complex changes to database structure may
require creating an entirely new database and copying
and converting data from the old database to the new
database.
• Utility programs supplied with the DBMS are used to
copy and convert the data.
• In more complex conversions, implementation staff
must develop programs to perform the conversion and
transfer some or all of the data.
Training Users
• Training Users
– is an essential part of any system deployment project
– two type of users
• end users
– people who use the system from day to day to achieve the
system’s business purpose.
• system operators
– people who perform administrative functions and routine
maintenance to keep the system operating.
Training Users
• Training Users
– Documentation and other training materials
• usually developed before formal user training begins.
• Each documentation type is targeted to a different
purpose and audience.
• Documentation can be loosely classified into two types:
– System documentation.
» Descriptions of system requirements, architecture, and
construction details
– User documentation.
» Descriptions of how to interact with and use the system
Training Users
• System Documentation
– provides information to developers and other technical
personnel who will maintain and upgrade the system.
– generated throughout the SDLC by each core process and
many development activities.
– System documentation developed during early project
iterations guides activities in later iterations, and
documentation developed throughout the SDLC guides
future system maintenance and upgrades
Training Users
• User Documentation
– provides ongoing support for end users of the system.
– describes routine operation of the system, including such
functions as data entry, output generation, and periodic
maintenance.
– Topics typically covered include the following:
• Software start-up and shutdown
• Keystroke, mouse, or command sequences required to perform
specific functions
• Program functions required to implement specific business
procedures (e.g., the steps followed to enter a new customer
order)
• Common errors and ways to correct them
Configuring the Production
Environment
• Configuring the Production Environment
– Modern applications are built from software components
based on interaction standards, such as
• Common Object Request Broker Architecture (CORBA),
• Simple Object Access Protocol (SOAP),
• Java Platform Enterprise Edition (Java EE).
• Microsoft .NET
– Each standard defines specific ways in which components
locate and communicate with one another.
Configuring the Production
Environment
• Configuring the Production Environment
– Each standard also defines a set of supporting system
software to provide needed services, such as maintaining
component directories, enforcing security requirements,
and encoding and decoding messages across networks and
other transport protocols.
– The exact system software, its hardware, and its
configuration requirements vary substantially among the
component interaction standards.
Configuring the Production
Environment
• Configuring the Production Environment
– The diagram shows a typical support infrastructure for an
application deployed using Microsoft .NET, a variant of
SOAP.
Configuring the Production
Environment
• Configuring the Production Environment
– Application software components written in such
programming languages as Visual Basic and C# are stored
on one or more application servers.
Configuring the Production
Environment
• Configuring the Production Environment
– Other required services include
• a Web server for browser-based
interfaces,
• a database server to manage the
database,
• an Active Directory server to
authenticate users and authorize
access to information and software
resources,
• a router and firewall, and
• a server to operate such low-level
Internet services as domain
naming system (DNS) and Internet
address allocation (DHCP).
Configuring the Production
Environment
• Configuring the Production Environment
– Unless it already exists, all this hardware and system software
infrastructure must be acquired, installed, and configured
before application software can be installed and tested.
– In most cases, some or all of the infrastructure will already
exist—to support existing information systems.
• In that case, developers work closely with personnel who
administer the existing infrastructure to plan the support for the
new system.
– In either case, this deployment activity typically starts early in
the project so software components can be developed, tested,
and deployed as they are developed in later project iterations.
Summary
The main activities for deployment are
• UAT
• Converting and Initializing Data
– Reusing Existing Databases
– Reloading Databases
• Training Users: End users and System operator
– System documentation for System operator
» Descriptions of system requirements, architecture, and
construction details
– User documentation.
» Descriptions of how to interact with and use the system
• Configuring the Production Environment
– Modern applications are built from software components based on
interaction standards. Each standard defines specific ways in which
components locate and communicate with one another.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 14
System Development Techniques
Diploma in Information Technology
Lesson 18
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Explain the difference types of deployment (direct,
parallel and phased)
Deployment
Deployment Approaches
• Deployment activities are highly interdependent with
activities of the other disciplines.
• A system or subsystem can’t be deployed until it has
been implemented and tested.
• If a system or subsystem is large and complex, it is
typically deployed in multiple stages or versions, thus
necessitating some formal method of configuration
and change management.
Deployment Approaches
• Important issues to consider when planning
deployment:
– Incurring costs of operating both systems in parallel
– Detecting and correcting errors in the new system
– Potentially disrupting the company and IS operations
– Training personnel and familiarizing customers with new
procedures
Deployment Approaches
• Different approaches to deployment represent
different trade-offs among cost, complexity, and risk.
The most commonly used deployment approaches
are:
– Direct deployment
– Parallel deployment
– Phased deployment
Direct Deployment
• Direct deployment (immediate cutover)
– The new system is installed and quickly made operational,
and any overlapping systems are then turned off.
– Both systems are concurrently operated for only a brief
time (typically a few days or weeks) while the new system
is being installed and tested.
Direct Deployment
• Direct deployment (immediate cutover)
– Advantage
• simplicity.
• Old and new systems aren’t operated in parallel,
• Fewer logistical issues to manage and fewer resources required.
– Disadvantage
• Risk.
• Older systems aren’t operated in parallel,
• No backup in the event that the new system fails.
Parallel Deployment
• Parallel deployment
– Old and new systems are operated for an extended period
of time (typically weeks or months).
– Ideally, the old system continues to operate until the new
system has been thoroughly tested and determined to be
error-free and ready to operate independently.
Parallel Deployment
• Parallel deployment
– Advantage
• Relatively low operational risk.
• Any failure in the new system can be mitigated by
relying on the old system.
– Disadvantage
• Cost - during the period of parallel operation, the
organization pays to operate both systems.
• Full parallel operation may be impractical
– New and old system are using the same hardware.
Parallel Deployment
• Parallel deployment
– A partial parallel operation may be employed if full parallel
operation is not possible
– Possible modes of partial parallel operation :
• Processing only a subset of input data in one of the two systems.
The subset could be determined by transaction type, geography, or
sampling (e.g., every 10th transaction).
• Performing only a subset of processing functions (e.g., updating
account history but not printing monthly bills).
• Performing a combination of data and processing function subsets.
Phased Deployment
• Phased deployment
– the system is deployed in a series of steps or
phases.
– Each phase adds components or functions to the
operational system.
– During each phase, the system is tested to ensure
that it is ready for the next phase.
– Phased deployment can be combined with parallel
deployment, particularly when the new system
will take over the operation of multiple existing
systems.
Phased Deployment
Phased Deployment
• The Phased deployment diagram shows
– A phased deployment with direct and parallel deployment
of individual phases.
– The new system replaces two existing systems.
– The deployment is divided into three phases. The first
phase is a direct replacement of one of the existing
systems.
– The second and third phases are different parts of a
parallel deployment that replace the other existing system.
Phased Deployment
• Phased deployment
– Advantage
• reduced risk because failure of a single phase is less problematic
than failure of an entire system.
– Disadvantage
• Cost and increased complexity.
• Dividing the deployment into phases creates more activities and
milestones, thus making the entire process more complex.
• However, each phase contains a smaller and more manageable set
of activities.
• If the entire system is simply too big or complex to install at one
time, the reduced risks of phased deployment outweigh the cost
and increased complexity
Summary
• If a system or subsystem is large and complex, it is typically
deployed in multiple stages or versions, thus necessitating
some formal method of configuration and change
management.
• Different approaches to deployment represent different
trade-offs among cost, complexity, and risk. The most
commonly used deployment approaches are:
– Direct deployment
– Parallel deployment
– Phased deployment
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 14
System Development Techniques
Diploma in Information Technology
Lesson 7
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Explain the elements of design
• Discuss the inputs and outputs for system design
Systems Design
• Analysis provides the starting point for design.
– Main focus is to understand the system
• Design provides the starting point for implementation as solution.
• Analysis and design document their results to coordinate the work of
multiple people and to communicate with downstream activities.
• Analysis activities create following models.
• class diagrams,
• use case diagrams,
• use case descriptions,
• activity diagrams,
• system sequence diagrams,
• state machine diagrams.
• The above are the System design inputs.
Systems Design
System Design
• System Design is also a model-building activity.
• Designers convert the information gathered during analysis—
the requirements models—into models that represent the
solution system.
• System design diagrams:
– Design class diagram
– Interaction diagrams (sequence diagrams)
– Design state machine diagrams
– Package diagrams
– Component diagrams
– Deployment diagrams
Systems Design
• Major models
used for
analysis and
design.
System Design Activities
• Specifying in detail how a system will work when deployed within a
specific technology environment.
• Some of the details may have been defined during systems analysis, but
much more detail is added during design.
• Each part of the final solution is heavily influenced by the design of all the
other parts. Thus, systems design activities are usually done in parallel.
– For example, the database design influences the design of application components,
software classes and methods, and the user interface.
– The technology environment drives many of the decisions for how system functions are
distributed across application components and how those components communicate
across a network.
• When an iterative approach to the SDLC is used, major design decisions
are made in the first or second iteration; however, many decisions are
revisited and refined during later iterations.
System Design Activities
System Design Activities
• System developers often ask themselves these questions to
help them stay focused on the objective of each design
activity.
Describe the Environment
• Describing the environment is the first design activity.
• Note the SA “Describes” the Environment and not “Design”
the Environment.
– Often the SA needs to work with what is currently existing in the
organisation.
– The new system must be designed to efficiently interact with the
current Environment.
– Some cases, a new system will require changes to existing technology
architecture. In those cases, any changes to the technology
architecture are considered and decided upon by the organization as a
whole.
• Consists of two key elements:
– External systems
– Technology architecture
Describe the Environment
• External systems
– Interactions among external systems are identified and described by
analysis activities.
– During analysis, those descriptions show how information flows to and
from external systems. (e.g. from activity diagram, sequence diagram)
• Information about incoming and outgoing messages is
needed, including:
– Precise message formats
– Web or network addresses of sources and destinations
– Communication protocols
– Security methods
– Error detection and recovery
Describe the Environment
• Technology architecture,
– set of computing hardware,
– network hardware and topology, and
– system software employed by an organization.
• A useful way of starting to describe the
environment is to pose a series of questions.
(see next slide)
Describing the Environment
• Questions:
– What are the key features of the existing or proposed technology
environment that will support or constrain the system?
– With what external systems and databases will the system under
development interact?
– What devices will be used for automated inputs and outputs?
– What user-interface technology will be used?
• The answers to those questions provide a pool of information
to be summarized in diagrams and supporting text.
• For a more comprehensive question list, see appendix
Design the Application Components
• A well-defined unit of software that performs one or more
specific tasks.
• Things to consider:
– Size/scope.
– Programming languages.
– Build or buy
• Key decisions made when designing application components
include
– how functions of the system will be grouped or packaged,
– how they’ll interact with one another once built (or acquired) and
assembled.
Design the Application Components
• One of the first steps in this design activity is separating the
software into subsystems.
• Decisions are also made about the database infrastructure
and about the multilayer design in which the user interface is
separated from the business logic and database processing.
• The technology architecture will impact many of these design
decisions.
Design the Application Components
Design the User Interface
• To the user of a system, the user interface is the system.
• The quality of the user interface can make or break a system
after deployment.
• Must deal with
– Multiple screens ranging from phones to large multi- monitor displays.
– Multitouch screens, voice recognition, and built-in cameras
– Users might interact with a system using one technology at their desk,
another in a conference room, and yet another while traveling.
Design the User Interface
• Both an analysis and design activity.
– Analysis:
• understanding the user’s needs;
• how the user carries out the job;
• physical contexts of user-system interactions.
– Design:
• distribution and packaging of related software
• determining which device capabilities and embedded
software will be incorporated into an interface
Design the Database
• The domain model class diagram is created early during
systems analysis and is then used to create the
implementation model of the database.
• Can be in a text file.
• Often, it is a relational database consisting of dozens or even
hundreds of tables that interact with each other.
• Sometimes, files and relational databases are used in the
same system.
• Might involve performance tuning to make sure the system
actually responds quickly enough
– Normalization, speed of retrieval, data redundancy, data consistency.
Design the Database
• Security and encryption issues, which are important
aspects of information integrity,
• Database may need to be replicated or partitioned at
various locations around the world.
• Databases may be distributed across multiple
database servers and may even be located at
completely different sites.
• These highly technical issues often require
specialized skills from experts in database design,
security, performance, and physical configuration.
Design the Software Classes and Methods
• Blueprints for software
methods that will be
programmed, tested,
and eventually deployed.
• Created based on other
models: sequence
diagrams, state-machine
diagrams, domain
diagram
System Controls and Security
• Modern systems are subject to a variety of
risks, ranging from malfunction due to
incorrect data input.
• Need to design the following into the System:
– Integrity Controls
– Security Controls
System Controls and Security
• Integrity Controls
– controls that reject invalid data inputs.
– prevent unauthorized data outputs.
– protect data and programs against accidental or
malicious tampering.
• Security Controls
– controls that protect the assets of an organization
from all threats, with a primary focus on external
threats.
Summary
• Systems design are activities that enable a
person to describe in detail how the resulting
information system will be implemented.
• The output artefacts from System analysis
becomes inputs to System design.
Summary
• The design activities are:
– Describe the environment
– Design the application components
– Design the user interface
– Design the database
– Design the software classes and methods
Summary
• The models that are produced in System
Design activities are:
– Component diagrams
– Deployment diagrams
– Design class diagrams
– Interaction diagrams (sequence diagrams)
– Design state machine diagrams
– Package diagrams
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 6
Appendix
• What are the key features of the existing or proposed
technology environment that will support or constrain the
system?
– What operating systems will be used?
– What other system software (e.g., Web server, database management,
and intrusion detection software) will be used?
– In what ways are network messages filtered or otherwise secured? Are
– any changes required to support interactions with external systems or
– user-interface devices?
– What APIs and development tools are compatible with the existing
technology environment?
Appendix
• With what external systems and databases will the system
under development interact? For each system or database,
answer the following questions:
– What is the timing and frequency of each interaction?
– What is the data content of inputs to and outputs from the system?
– What protocols will format and encode data flowing to or from the
– external system?
– What are the security requirements of each inflow and outflow?
– What security methods and protocols will be used to satisfy the
security requirements?
Appendix
• What devices will be used for automated inputs and outputs?
– What protocols will format and encode data flowing to or from the
devices?
– What are the security requirements of each inflow and outflow?
– What security methods and protocols will be used to satisfy the
security requirements?
– What APIs and development tools are compatible with the existing
– technology environment and required automated inputs and outputs?
Appendix
• What user-interface technology will be used?
– Where will users be located?
– What hardware device(s) will users use?
– What operating systems will run on “smart” user-interface devices?
– On what other user device software will the system rely (e.g.,
browsers, plug-ins, and software utilities embedded in the device)?
– What protocols will format and encode data flowing to or from user
devices?
– What are the security requirements of each inflow and outflow?
– What security methods and protocols will be used to satisfy the
security requirements?
– What APIs and development tools are compatible with the existing
technology environment and required user interfaces?
System Development Techniques
Diploma in Information Technology
Lesson 11
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Discuss the systems development life cycle
• Explain the support phase
The System Development Life Cycle
• The SDLC : a way to think about the development of
a new system as a progressive process.
• During its life cycle, an information system is
– first conceived,
– then it is designed, built, and deployed as part of a
development project, and,
– finally, it is put into production and used to support the
business.
The System Development Life Cycle
• Even during the productive use, a system is still a
dynamic, it is updated, modified, and repaired
through smaller projects.
• Several projects may be required during the life of a
system,
– first to develop the original system and
– then to upgrade.
The System Development Life Cycle
• Many approaches to developing systems, and they are based
on different approaches to the SDLC.
• Difficult to find a single, comprehensive classification system
that encompasses all the approaches.
• One useful way to categorize them is along a continuum from
predictive to adaptive.
The System Development Life Cycle
• Predictive approach to the SDLC
– assumes that the development project can be planned and
organized and that the new information system can be
developed according to the plan.
– useful for building systems that are well understood and
defined.
– For example, a company may want to convert its old
networked client/server system to a newer Web-based
system that includes a smartphone app. In this type of
project, the staff already understands the requirements
very well, and no new processes need to be added. Thus,
the project can be carefully planned, and the system can
be built according to the specifications.
The System Development Life Cycle
• Adaptive approach to the SDLC
– when the system’s requirements and/or the users’ needs
aren’t well understood.
– the project can’t be planned completely. Some system
requirements may need to be determined after
preliminary development work.
– Developers should still be able to build the solution, but
they need to be flexible and adapt the project as it
progresses.
The System Development Life Cycle
• Predictive and Adaptive approach to the SDLC
– In practice, any project could have—and most do have—
predictive and adaptive elements.
– The figure shows them as endpoints along a continuum,
not as mutually exclusive categories.
The System Development Life Cycle
• Traditional Predictive Approaches to the SDLC
– Six groups of activities
1. Project initiation
• activities that identify the problem and secures approval to
develop a new system;
2. Project planning
• activities, involves planning, organizing, and scheduling the
project. These activities map out the project’s overall structure.
3. Analysis
• focuses on discovering and understanding the details of the
problem or need. Figure out exactly what the system must do to
support the business processes.
The System Development Life Cycle
• Traditional Predictive Approaches to the SDLC
4. Design
• focuses on configuring and structuring the new system
components.
• use the requirements that were defined earlier to develop the
program structure and the algorithms for the new system.
5. Implementation
• includes programming and testing the system.
6. Deployment
• involves installing and putting the system into operation.
• The six group of activities provide the framework for
managing the project.
The System Development Life Cycle
• Traditional Predictive Approaches to the SDLC
– Another phase, support phase,
• includes activities needed to upgrade and maintain the system
after it has been deployed.
• support phase is part of the overall SDLC, but not considered part
of the initial development project
– Activities are carried out sequentially rather than repeated
in each iteration.
The System Development Life Cycle
• Waterfall model
– with the phases of the project flowing down, one after
another.
The System Development Life Cycle
• Waterfall model
– assumes that the phases can be carried out and completed
sequentially.
– After a project drops over the waterfall into the next
phase, there is no going back.
– assumes rigid planning and final decision making at each
step of the development project.
– doesn’t always work very well.
• Being human, developers are rarely able to complete a phase
without making mistakes or leaving out important components
that have to be added later.
The System Development Life Cycle
• Modified Waterfall model
– project’s phases overlap, influencing and depending on
each other.
– still predictive
The System Development Life Cycle
• Adaptive Approaches to the SDLC
– All project activities are included in each iterations.
– Iterations can be used to create a series of mini-projects
that address smaller parts of the application.
• One of these smaller parts is analyzed, designed, built, and tested
during a single iteration; then, based on the results, the next
iteration proceeds to analyze, design, build, and test the next
smaller part.
The System Development Life Cycle
• Adaptive Approaches to the SDLC
– the project is able to adapt to any changes as it proceeds.
– parts of the system are available early on for user
evaluation and feedback, which helps ensure that the
application will meet the needs of the users.
– The above idea is known as incremental development.
The System Development Life Cycle
• Incremental development.
– based on an iterative life cycle.
– system is built in small increments.
– An increment may be developed within a single iteration
or it may require two or three iterations.
– As each increment is completed, it is integrated with the
whole.
– The system, in effect, is “grown” in an organic fashion. The
advantage of this approach is that portions of the system
get into the users’ hands much sooner so the business can
begin accruing benefits as early as possible.
The System Development Life Cycle
• Walking skeleton.
– provides a complete front-to-back implementation of the new system
but with only the “bare bones” of functionality.
– is developed in a few iterations early in the project.
– add on the “flesh” (i.e. more functions and capabilities) in later
iterations
– gets working software into the hands of the users early in the project.
• Incremental development and Walking skeleton approaches
have the additional advantage of extensive user testing and
feedback to the project team as the project progress.
Summary
• The SDLC : a way to think about the development of
a new system as a progressive process.
• Adaptive Approaches to the SDLC
– All project activities are included in each iteration.
– Iterations can be used to create a series of mini-projects
that address smaller parts of the application.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 10
System Development Techniques
Diploma in Information Technology
Lesson 14
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Explain the design with communication
diagrams
• Design object-oriented and use case
realisation
Object-Oriented Design with
Interaction Diagrams
• Use case realization
– the process of extending detailed design
– each use case is taken individually to determine all the
classes that collaborate on it.
– any other utility or support classes are identified.
• E.g. UI, Controller and database
– As the details of the classes are designed—use case by use
case—the design class diagram is also updated as
necessary.
Object-Oriented Design with
Interaction Diagrams
• Interaction diagrams
– heart of object- oriented design.
– realization of a use case
• determining what objects collaborate and
• the messages they send to each other to carry out the use case
(interaction diagram)
– Two types
• communication diagrams and sequence diagrams.
Object-Oriented Design with
Interaction Diagrams
• Communication diagrams
– a little less detailed
– provide a broad “overview” picture of the interactions.
– works best for use cases that are not too large with many
messages.
– provides a snapshot view of the classes and messages.
– Disadvantage: not much space allowed for messages, can
easily become cluttered with overlapping information.
• Sequence diagrams
– more detailed and allow the designer to visually document
the process flow of the messages
Use Case Realization with
Communication Diagrams
• Communication diagram
– consists of actors, objects, links, and messages.
Use Case Realization with
Communication Diagrams
• Actor
– represents an external role of the person or thing
that initiates the use case by sending the initial
message and any other messages to the system.
– Messages:
• come into the system through data that is entered on
forms.
• come electronically by other external devices or
systems.
Use Case Realization with
Communication Diagrams
• Object
– instantiated class objects that perform actions to
help carry out the use case.
– can both receive messages and send messages.
– object notation: a colon and underlining
Use Case Realization with
Communication Diagrams
• Link
– connectors that illustrate the flow of the
messages.
– show where the messages flow.
• Messages can flow in either direction on a link.
Use Case Realization with
Communication Diagrams
• Message
– Send from an object or actor to an object or actor.
– is a request for service.
– can return data from a previous message.
– invoke a service in an object.
– In programming terms, a message is the same as a
procedure call or a method call.
Use Case Realization with
Communication Diagrams
• Message syntax
– [true/false condition] sequence-number:
return-value: = message-name (parameter-list)
Use Case Realization with
Communication Diagrams
• Message syntax
– True/false condition.
• condition that is tested for true or false.
• if it is true, then the message is sent;
• if false, the message is not sent.
• only applies to sending the message.
• optional.
Use Case Realization with
Communication Diagrams
• Message syntax
– Sequence number.
• used to identify the order of the messages.
• use hierarchical dot notation (i.e., 1.0, 1.2, 2.1.3, etc.)
• if a use case has two separate input messages, each
with several subsequent messages that travel the same
links, they could be uniquely partitioned by using 1.0
and 2.0 series.
Use Case Realization with
Communication Diagrams
• Message syntax
– Return-value
• value that the message returns after the completion of
the service requested in the forward part of the
message.
• In programming terms, this is similar to a method
return value.
• Return values can be returned either with this format
(i.e., as part of the message) or as a separate return
message.
Use Case Realization with
Communication Diagrams
• Message syntax
– Message-name
• usually uses camel case with the initial letter lowercase.
• name the message by describing the service that is
requested from the destination object.
• For example, createAccount could be a message name
that requests the specific service from the destination
object.
• if a return-value is given, the name and return value are
separated by “:=”.
Use Case Realization with
Communication Diagrams
• Message syntax
– Parameter-list.
• contains items that are being passed to the destination
object via the message.
• in programming terms, these are the arguments.
Use Case Realization with
Communication Diagrams
• The following diagram shows a prelim
communication diagram for the Create customer
account use case.
Use Case Realization with
Communication Diagrams
• Create customer account use case.
– asterisk between the number and the name
indicates that the message may be sent multiple
times.
– a multiply occurring message.
Use Case Realization with
Communication Diagrams
• Next enhance the first cut Design Class diagram using
communication diagram to produce the final design
class diagram for the use case.
– first-cut design class diagram gives a preliminary idea of
what domain classes will be involved and the logical
navigation visibility relationships.
– helpful to have either an activity diagram or a system
sequence diagram and a detailed use case description for
the final design class diagram.
Use Case Realization with
Communication Diagrams
Use Case Realization with
Communication Diagrams
First-cut design class diagram for Create customer account
Use Case Realization with
Communication Diagrams
System sequence diagram for Create customer account
Use Case Realization with
Communication Diagrams
• Extend Input Messages
– For each input message, extend the message to the
internal objects within the :System object. Follow this
process:
• Step 1:
– From the first-cut design class diagram, identify the classes
that will be required to carry out the execution of the
message.
• Place the corresponding objects on the diagram.
– Example: The required classes for this message are
CustomerHandler and Customer.
Use Case Realization with
Communication Diagrams
• Step 2:
– Beginning with the input message, identify each message
that will be required for each of the included objects on
the diagram.
– For each message, ensure that the origin object has
navigation visibility to the destination object.
– Determine which object should have primary responsibility
for completing the required service.
– Place appropriate messages based on navigation and
responsibility.
Use Case Realization with
Communication Diagrams
• Step 2:
• Example:
– The required message is createNewCustomer and comes
from the Clerk to the :CustomerHandler.
– The :CustomerHandler then forwards that same message
to the :Customer object.
– The :Customer object is the appropriate object to carry out
this service.
– The constructor method in the Customer class instantiates
a new :Customer object.
– This is shown in the diagram with a message directly to the
:Customer object.
Use Case Realization with
Communication Diagrams
• Step 3
– Name each message to reflect the service requested from
the destination object.
– Identify and include the parameters that the destination
object will require to carry out the requested service.
– Identify and name any return messages or return values
that need to be returned to origin objects.
Use Case Realization with
Communication Diagrams
• Step 3
– Example
– The name of the message is appropriate as given in the
SSD.
– The parameters on the SSD, however, do not reflect the
attributes of the Customer class.
– The accountNo and status attributes are both determined
by the constructor.
– The other attributes—name, mobilePhone, homePhone,
and emailAddress—need to be passed in as arguments.
– The input parameter list will be modified to reflect these
changes.
Use Case Realization with
Communication Diagrams
Use Case Realization with
Communication Diagrams
Use Case Realization with
Communication Diagrams
Use Case Realization with
Communication Diagrams
Final communication diagram for Create customer account use case
Use Case Realization with
Communication Diagrams
• The final communication diagram for this use case is
show in the previous slide.
• All the return messages are included in this final
diagram.
• The diagram contains only problem domain objects
and does not include view layer or data access layer.
• Identify the messages in the communication diagram
and add those messages as methods in each class.
Use Case Realization with
Communication Diagrams
Design class diagram for methods added from Create customer account
Summary
• Use case realization is the process of extending detailed
design
• Interaction diagrams
– is the heart of object- oriented design.
– realization of a use case
• determining what objects collaborate and
• the messages they send to each other to carry out the use case
(interaction diagram)
– Two types
• communication diagrams and sequence diagrams.
Summary
• Communication diagrams
– a little less detailed
– provide a broad “overview” picture of the interactions.
– works best for use cases that are not too large with many
messages.
– provides a snapshot view of the classes and messages.
– Disadvantage: not much space allowed for messages, can
easily become cluttered with overlapping information
– consists of actors, objects, links, and messages.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 13
System Development Techniques
Diploma in Information Technology
Lesson 19
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Describe the elements of the Unified Process
(UP)
• Compare and contrast the features of Extreme
Programming and Scrum Development
The Unified Process, Extreme
Programming, and Scrum
• The Agile philosophy
– has proven to be an effective way to approach software
development in today’s fast-paced, continually changing
landscape of computer applications.
– only proposes principles; it isn’t meant to be a complete
methodology, with practices and action steps.
• Three methodologies that incorporate Agile
principles
– The Unified Process, (UP)
– Extreme Programming, (XP)
– Scrum
The Unified Process, Extreme
Programming, and Scrum
• Organizations either mix and match techniques from
the three or only adopt a specific set of practices.
• Adoption of these methodologies continues to
expand throughout all types of organizations that
develop software applications.
The Unified Process
• An object-oriented system development
methodology.
• Defines a complete methodology that uses UML for
system models and describes a new, adaptive system
development life cycle.
• based on an iterative approach
– each iteration is like a mini-project,
• requirements are defined based on analysis tasks,
system components are designed, and those
components are then implemented—at least
partially—through programming and testing.
The Unified Process
• The UP divides a project into four major
phases.
• Each phases has a different focus.
– Inception Phase
– Elaboration Phase
– Construction Phase
– Transition Phase
The Unified Process
• UP Phases
– Each phase describes the emphasis or objectives
of the project team members and their activities
at that point in time.
– provide a general framework for planning and
tracking the project over time.
– Within each phase, several iterations are planned
to give the team enough flexibility to adjust to
problems or changing conditions.
The Unified Process
• Inception
– Develop an approximate vision of the system,
– make the business case,
– define the scope,
– produce rough estimates for cost and schedule.
– usually completed in one iteration
The Unified Process
• Elaboration Phase
– a high percentage of time is spent on
understanding and analysis.
– identify and describe all requirements,
– finalize the scope, design
– implement the core architecture and functions,
– produce realistic estimates for cost and schedule
The Unified Process
• Elaboration Phase
– resolve high risks,
• the aspects of the system that pose the greatest risk are identified
and implemented first.
• Until developers know exactly how the highest-risk aspects of the
project will work out, they can’t determine the amount of effort
required to complete the project
– the requirements are expected to evolve and
change after work starts on the project.
– usually involves several iterations
The Unified Process
• Construction Phase
– Iteratively implement the remaining lower-risk,
predictable, and easier elements and prepare for
deployment.
• for example, detailing the system controls, such as data
validation, fine-tuning the user-interface design,
finishing routine data maintenance functions, and
completing the help and user preference functions.
– begins to plan for deployment of the system.
The Unified Process
• Transition Phase
– one or more final iterations involve the final user
acceptance and beta tests, and the system is
made ready for operation.
– After the system is in operation, it will need to be
supported and maintained.
The Unified Process
• UP Disciplines
– defines disciplines to use within each iteration.
– a set of functionally related activities that contributes to
one aspect of the development project.
– include business modelling, requirements, design,
implementation, testing, deployment, configuration and
change management, project management, and
environment.
– Each iteration usually involves activities from all
disciplines.
The Unified Process
• UP Disciplines
– each iteration,
typically last four
weeks.
– size of the shaded
area under the
curve for each
discipline indicates
the relative amount
of work included
from each
discipline during
the iteration
The Unified Process
• UP Disciplines
– divided into two main categories:
• system development activities
– business modelling, requirements, design,
implementation, testing, deployment
• project management activities.
– configuration and change management, project
management, and environment.
The Unified Process
• UP Phase and Disciplines
UP Phase Objective
Inception
Develop an approximate vision of the
system, make the business case,
define the scope, and produce rough
estimates for cost and schedule.
Elaboration
Define the vision, identify and
describe all requirements, finalize the
scope, design and implement the core
architecture and functions, resolve
high risks, and produce realistic
estimates for cost and schedule.
Construction
Iteratively implement the remaining
lower-risk, predictable, and easier
elements and prepare for
deployment.
Transition
Complete the beta test and
deployment so users have a working
system and are ready to benefit as
expected.
The Unified Process
• UP Phase and Disciplines
– All nine UP disciplines are employed throughout
the lifetime of a project but to different degrees.
– inception phase,
• the project manager might complete a model showing
some aspect of the system environment
• the scope of the system is shown by defining many of
the key system requirements and listing use cases (the
requirements discipline).
The Unified Process
• UP Phase and Disciplines
– inception phase,
• To prove technological feasibility, some technical aspect
of the system might be
– designed (the design discipline),
– programmed (the implementation discipline), and
– tested to make sure it will work as planned (the
testing discipline).
The Unified Process
• UP Phase and Disciplines
– inception phase,
• the project manager
– makes plans for handling changes to the project
(the configuration and change management
discipline),
– working on a schedule and cost/benefit analysis
(the project management discipline), and
– tailoring the UP phases, iterations, deliverables, and
tools to match the needs of the project (the
environment discipline).
The Unified Process
• UP Phase and Disciplines
– elaboration phase
• includes several iterations.
• the team works on
– the details of the domain classes and use cases
addressed in the iteration (the business modeling
and requirements disciplines).
– complete the description of all use cases to finalize
the scope (the requirements discipline).
The Unified Process
• UP Phase and Disciplines
– elaboration phase
• the team works on
– The use cases addressed in the iteration are designed by
creating design class diagrams and interaction diagrams (the
design discipline),
– programmed using e.g. Java (the implementation discipline),
– fully tested (the testing discipline).
– The project manager works on the plan for the next iteration
and continues to refine the schedule and feasibility
assessments (the project management discipline),
– all team members continue to receive training on the UP
activities they are completing and the system development
tools they are using (the environment discipline).
The Unified Process
• UP Phase and Disciplines
– construction phase,
• most of the use cases have been designed and implemented
in their initial form.
• focus of the project turns to satisfying other technical,
performance, and reliability requirements for each use case,
finalizing the design, and implementing the design.
• these requirements are usually routine and lower risk, but
they are key to the success of the system.
• the effort focuses on designing system controls and security
and on implementing and testing these aspects.
The Unified Process
• UP Disciplines
• project management activities.
– Configuration and change management
• involves setting up processes to support the coding
activities.
• includes guidelines as when and how to release code as
well as when and how to manage releases and versions.
– Project management
• planning the iterations, assigning work, and verifying
that work has been completed.
The Unified Process
• UP Disciplines
• project management activities.
– Environment
• involves those tasks required to establish the working
environment,
– tools to be used by the team.
– guidelines about how to work together in an
iterative Agile project.
The Unified Process
• Unified Process
– should always be tailored to the project,
– tailored to the development team and the specific
project.
– choices must be made about which deliverables to
produce and the level of formality, or ceremony,
to be used.
– Sometimes, a project requires formal reporting
and controls. Other times, it can be less formal.
Extreme Programming (XP)
• An adaptive Agile development methodology
• Attempt to take the best practices of software
development and extend them “to the extreme.”
• Extreme programming has these characteristics:
– Takes proven industry best practices and focuses on them
intensely
– Combines those best practices (in their most intense
forms) in a new way to produce a result that is greater
than the sum of its parts
Extreme Programming (XP)
• XP core values and practices
Extreme Programming (XP)
• XP core values
– communication,
– simplicity,
– feedback, and
– courage
Extreme Programming (XP)
• XP core value: Communication.
– One of the major causes of project failure is a lack
of open communication among the right players
at the right time and at the right level.
– Effective communication involves not only
documentation, but also verbal discussion.
– The practices and methods of XP are designed to
ensure that open, frequent communication
occurs.
Extreme Programming (XP)
• XP core value: Simplicity.
– includes techniques to reinforce this principle and
make it a standard way of developing systems.
• XP core value: Feedback
– getting frequent, meaningful feedback is
recognized as a best practice of software
development.
– Feedback on functionality and requirements
should come from the users, feedback on designs
Extreme Programming (XP)
• XP core value: Courage.
– Developers always need courage to face the harsh
choice of doing things right or throwing away bad
code and starting over.
– too frequently, they haven’t had the courage to
stand up to a too-tight schedule, resulting in bad
mistakes.
– XP practices are designed to give developers the
courage to “do it right.”
Extreme Programming (XP)
• XP Practices
Extreme Programming (XP)
• XP Practices – Planning
– focuses on making a rough plan quickly and then refining it
as things become clearer.
– basis of an XP plan is a set of stories that users develop. A
story describes what the system needs to do.
– XP doesn’t use the term use case, but a user story and a
use case express a similar idea.
Extreme Programming (XP)
• XP Practices – Planning
– Planning involves two aspects: business issues and
technical issues.
• business issues are decided by the users and clients,
• technical issues are decided by the development team.
– The plan, especially in the early stages of the project,
consists of the list of stories (from the users) and the
estimates of effort, risk, and work dependencies for each
story (from the development team).
– heavily involve the users in the project rather than have
them to simply sign off on specifications.
Extreme Programming (XP)
• XP Practices – Testing
– tests for each story be written first—before the solution is
programmed.
– two major types of tests:
• unit tests : test the correctness of a small piece of code, and
• acceptance tests : test the business function.
– The developers write the unit tests,
– The users write the acceptance tests.
Extreme Programming (XP)
• XP Practices – Testing
– Before any code can be integrated into the library of the
growing system, it must pass the tests.
– Automates the test and executes them frequently.
– Over time, a library of required tests is created,
– when requirements change and the code needs to be
updated, the tests can be rerun quickly and automatically.
Extreme Programming (XP)
• XP Practices - Pair Programming
– divides up the coding work.
• one programmer might focus more on design and double-checking
the algorithms,
• the other writes the code.
– Then, they switch roles; thus, over time, they both think
about design, coding, and testing.
– XP relies on comprehensive and continual code reviews.
– Interestingly, research has shown that pair programming is
more efficient than programming alone.
Extreme Programming (XP)
• XP Practices - Pair Programming
– It takes longer to write the initial code, but the long-term
quality is higher.
– Errors are caught quickly and early, two people become
familiar with every part of the system, all design decisions
are developed by two brains, and fewer “quick and dirty”
shortcuts are taken.
– The quality of the code is always higher in a pair-
programming environment.
Extreme Programming (XP)
• XP Practices - Simple Designs
– done continually in small chunks.
– design must be verified immediately by reviewing it along
with coding and testing.
– what is a simple design?
• one that accomplishes the desired result with as few classes and
methods as possible
• doesn’t duplicate code.
• Accomplishing all that is often a major challenge.
Extreme Programming (XP)
• XP Practices - Refactoring the Code
– Refactoring is the technique of improving the code without
changing what it does.
– Before and after adding any new functions, XP
programmers review their code to see whether there is a
simpler design or a simpler method of achieving the same
result.
– Research on Software Design Pattern.
– Produces high-quality, robust code.
Extreme Programming (XP)
• XP Practices - Owning the Code Collectively
– everyone is responsible for the code.
– No one person can say, “This is my code.”
– Someone can say, “I wrote it,” but everyone owns it.
– Allows anyone to modify any piece of code.
– Unit tests are run before and after every change, if
programmers see something that needs fixing, they can
run the unit tests to make sure the change didn’t break
something.
– This practice embodies the team concept that developers
are building a system together.
Extreme Programming (XP)
• XP Practices - Continuous Integration
– Small pieces of code—which have passed the unit tests—
are integrated into the system daily or even more often.
– Continuous integration highlights errors rapidly and keeps
the project moving ahead.
– The traditional approach of integrating large chunks of
code late in the project often resulted in tremendous
amounts of rework and time lost while developers tried to
determine just what went wrong.
– XP’s practice of continuous integration prevents that.
Extreme Programming (XP)
• XP Practices - On-Site Customer
– require continual involvement of users who can make
business decisions about functionality and scope.
– Based on the core value of communication, this practice
keeps the project moving ahead rapidly.
– If the customer isn’t ready to commit resources to the
project, the project won’t be very successful.
Extreme Programming (XP)
• XP Practices - System Metaphor
– “a story that everyone - customers, programmers, and
managers - can tell about how the system works.”
– It answers the questions “How does the system work?”
and “What are its major components?”
Extreme Programming (XP)
• XP Practices - System Metaphor
– Some metaphors are used repeatedly in software
development. Some common approaches:
• Spreadsheet Metaphor
• Script Metaphor
• Manufacturing Metaphor (e.g. AssemblyLine)
• Shopping Cart Metaphor (e-commerce)
• Auction Metaphor (e-commerce)
• Document Processor (desktop systems where the “model” gets
saved as a file)
• Virtual Space Metaphor (eg. VR)
Extreme Programming (XP)
• XP Practices – Small Releases
– a point at which the new system can be turned over to
users for acceptance testing and even for productive use.
– small and frequent releases provide upgraded solutions to
the users and keep them involved in the project.
– Frequent releases also facilitate other practices, such as
immediate feedback and continual integration.
Extreme Programming (XP)
• XP Practices – Forty-Hour Week and Coding
Standards
– set the tone for how the developers should work.
– exact number of hours a developer works isn’t the issue.
– issue is that the project shouldn’t be a death march that
burns out every member of the team.
– Neither should the project be a haphazard coding exercise.
– Developers should follow standards for coding and
documentation.
Extreme Programming (XP)
• XP Project Activities
Scrum
• In Rugby game, a scrum,
– is to get a ball back into play after a penalty.
– begins quickly, very intense effort, involves the entire team, and
usually only lasts for a short duration.
• Objective is to be quick, agile, and intense and to go the entire
distance.
• There are three important Scrum areas to understand:
– the philosophy,
– the organization, and
– the practices.
Scrum
An overview of the Scrum approach
Scrum
• Scrum Philosophy
– responsive to a highly changing, dynamic environment in
which users might not know exactly what is needed and
might also change priorities frequently.
– Software is developed incrementally, and controls are
imposed empirically—by focusing on things that can be
accomplished.
– The basic control mechanism for a Scrum project is a list of
all the things the system should include and address.
• This list—called the product backlog
Scrum
• Scrum Philosophy
– product backlog
• includes user functions (such as use cases), features
(such as security), and technology (such as platforms).
• The product backlog list is continually being prioritized,
• Only a few of the high-priority items are worked on at a
time, according to the current needs of the project.
Scrum
• Scrum Organization
– product owner
• the client, with additional responsibilities.
• maintains the product backlog list.
• any function to be included in the final system, it must first
be placed on the product backlog.
• any request must first be approved and agreed to by the
product owner.
– In a Scrum project, the client controls the requirements. This forces
the client and user to be intimately involved in the project.
– Nothing can be accomplished until the product owner creates the
backlog.
Scrum
• Scrum Organization
– product owner
• In a Scrum project, the client controls the
requirements. This forces the client and user to be
intimately involved in the project.
• Nothing can be accomplished until the product owner
creates the backlog.
Scrum
• Scrum Organization
– Scrum master
• comparable to a project manager
• enforces Scrum practices and helps the team complete
its work.
• hindrance so the team can do its work.
• focal point for communication and progress reporting
• doesn’t set the schedule or assign tasks, The team
does.
• protects the team from any intrusions.
Scrum
• Scrum Organization
– Scrum team
• a small group of developers—typically five to nine
people
• for projects that are very large, the work should be
partitioned and delegated to smaller teams.
• if necessary, the Scrum masters from all the teams can
coordinate multiple team activities.
Scrum
• Scrum Organization
– Scrum team
• sets its own goal for what it can accomplish in a specific
period of time.
• organizes itself and parcels out the work to members.
• In a small team, it is much easier to sit around a table,
decide what needs to be done, and have members of
the team volunteer or accept pieces of work.
Scrum
• Scrum Organization
– Scrum team
• Team members do talk with users to obtain
requirements, and users are involved in the sprint’s
work.
• Users can’t change the items being worked on from the
backlog list or change the intended scope of any item
without putting it on the backlog list.
Scrum
• Scrum Practices
– mechanics of how a project progresses.
– basic work process is called a sprint,
• all other practices are focused on supporting a sprint.
– A Scrum sprint
• a firm period called a time box, with a specific goal or
deliverable.
Scrum
• Scrum Practices
– A Scrum sprint
• Beginning of a sprint
– the team gathers for a one-day planning session.
– the team decides on the major goal for the sprint.
– the goal draws from several items on the prioritized product
backlog list.
– the team decides how many of the highest-priority items it
can accomplish within the sprint.
– Sometimes, lower-priority items can be included for very little
additional effort and can be added to the deliverables for the
sprint.
Scrum
• Scrum Practices
– A Scrum sprint
• After the goal has been agreed and items selected from
the backlog list, it begins work.
– The scope of that sprint is then frozen, and no one can change
it—neither the product owner nor any other users.
– If users do find new functions they want to add, they put
them on the product backlog list for the next sprint.
– If team members determine that they can’t accomplish
everything in their goal, they can reduce the scope for that
sprint.
– The time period is kept constant.
Scrum
• Scrum Practices
– Scrum planning meeting
• Every day the Scrum master holds a meeting with all
members of the team.
• Objective is to report progress.
• limited to 15 minutes or some other short time period.
• Members of the team answer only three questions:
– What have you done since the last daily Scrum (during the last
24 hours)?
– What will you do by the next daily Scrum?
– What kept you or is keeping you from completing your work?
Scrum
• Scrum Practices
– At the end of each sprint,
• the agreed-on deliverable is produced.
• A final half-day review meeting is scheduled to recap
progress and identify changes that need to be made for
the following sprints.
• By time-boxing these activities— the planning, the
sprint, the daily Scrum, and the Scrum review—the
process becomes a well-defined template to which the
team easily conforms, which contributes to the success
of Scrum projects.
Summary
• The Agile philosophy has proven to be an effective
way to approach software development in today’s
fast-paced, continually changing landscape of
computer applications.
• It is only proposes principles; it isn’t meant to be a
complete methodology, with practices and action
steps.
• Three methodologies that incorporate Agile
principles are The Unified Process, (UP), Extreme
Programming, (XP) and Scrum.
Summary
• The Unified Process defines a complete
methodology that uses UML for system
models and describes a new, adaptive system
development life cycle.
Summary
• Extreme Programming is an adaptive, Agile
development methodology
• An attempt to take the best practices of software
development and extend them “to the extreme.”
Extreme programming has these characteristics:
– Takes proven industry best practices and focuses on them
intensely
– Combines those best practices (in their most intense
forms) in a new way to produce a result that is greater
than the sum of its parts
Summary
• Objective is to be quick, agile, and intense and to go the entire
distance.
• There are three important Scrum areas to understand:
– the philosophy,
– the organization, and
– the practices.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 10
System Development Techniques
Diploma in Information Technology
Lesson 15
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Explain use case realisation with sequence
diagrams
• Describe the MVC design pattern
Use Case Realization
Use Case Realization with
Sequence Diagrams
• Design process for sequence diagrams is the same as
communication diagrams.
– Starts with SSD and first-cut design class diagram.
• Other models, such as a use case description and activity diagram,
are also helpful.
– SSD only has two lifelines—one for the actor and one for
the system.
– Starting with the SSD, each input message is taken, one at
a time, and extended to all of the internal classes so that
the desired result is obtained. Any data to be returned is
identified and added.
Use Case Realization with
Sequence Diagrams
• Below is the sequence diagram solution of the Create
customer account use case.
– Developed using the same three steps that were used to extend
communication diagram messages.
• Has the same set of messages, but displayed differently.
• Primary benefit of the sequence diagram is the ability to lay
out the messages from top to bottom to emphasize the
sequence of firing.
Use Case Realization with
Sequence Diagrams
Sequence diagram
from Create
customer account
use case
Communication
diagram from
Create customer
account use case
Use Case Realization with
Sequence Diagrams
• Sequence Diagram
– The actor is an external role, in this case, a Clerk.
– The boxes are instantiated objects from the corresponding
classes. Object notation is used. E.g. aC:Customer.
Use Case Realization with
Sequence Diagrams
• Sequence Diagram
– Below each actor and object is a lifeline, which is used as
an indicator of the life of the object.
Use Case Realization with
Sequence Diagrams
• Sequence Diagram
– Attached to locations of each lifeline are vertical boxes representing
activation lifelines.
• time period when a method is executing.
Use Case Realization with
Sequence Diagrams
• Sequence Diagram
– Messages are attached to the lifeline either as a source
point or a destination point.
Use Case Realization with
Sequence Diagrams
• Sequence Diagram
– Two ways to indicate data being returned,
• by a return assignment with the “:=” operator, or
• as a return message using a dashed arrow.
Use Case Realization with
Sequence Diagrams
• When a message is sent from an originating object to a
destination object, in programming terms, it means that the
originating object is invoking a method on the destination
object.
• Thus, by defining the messages to various internal objects, we
are actually identifying the methods of that object.
• Once a use case is realized with this detailed design process,
the set of classes and required methods can be extracted so
programming can be completed.
Use Case Realization with
Sequence Diagrams
• Good design principles
– Use case controller provides the link between the internal
objects and the external environment.
– Responsibilities assigned to :CustomerHandler are to catch
incoming messages, distribute them to the correct internal
domain objects, and return the required information to
the external environment.
Use Case Realization with
Sequence Diagrams
• Good design principles
– The responsibility assigned to :Customer is to be in charge
of creating itself and to control the other required updates
to subordinate objects.
– The :Address and :Account objects create themselves.
– The assignment of responsibilities and corresponding
messages conforms to good design principles.
– Other issues will need to be addressed as the design
expands to include three layers.
Developing a Multilayer Design
• So far in the development of the sequence diagram,
we have focused only on the classes in the problem
domain layer.
• In many instances, this may be sufficient
documentation to program the solution—either by
yourself or with another programmer.
• Once you have a solid design for the problem domain
classes, adding the view layer and the data access
layer is a straightforward process.
Developing a Multilayer Design
• Add customer account use case with view layer added
view layer
Developing a Multilayer Design
• Designing the View Layer
– Add an object for each input form or screen.
Developing a Multilayer Design
• Designing the View Layer
– Add the appropriate messages from the Actor to the input
«view» objects.
Developing a Multilayer Design
• Designing the View Layer
– Messages are added for
• the :CustWindow to open the :AddrWindow,
• the :AddrWindow to open the :AcctWindow.
Developing a Multilayer Design
• Designing the Data Access Layer
– Purpose of data access layer is Principle of separation of
responsibilities.
– For complex systems, designers create three-layer designs,
including classes whose sole responsibility is executing
database SQL statements, getting the results of the query,
and providing the information to the domain layer.
– Multilayer design was used to support multitier networks
in which the database server was on one machine, the
business logic was on another server, and the user
interface was on several desktop client machines. This way
of designing systems creates more robust and more
flexible systems.
Developing a Multilayer Design
• Designing the Data Access Layer
– When an object is updated, it also needs to be written to
the database.
– Send a message to the data access object together with
the required parameters.
– The data access method can pull out the attributes, format
an SQL insert or update statement, and write it to the
database.
Developing a Multilayer Design
• Designing the Data Access Layer
Data Access Layer
Developing a Multilayer Design
• Designing the Data Access Layer
– Addition three data access objects and have the newly
created objects send messages to write themselves out to
the database.
– The diagram is organized with
• the view layer on the left,
• the problem domain layer in the middle, and
• the data access layer on the right.
Packaging the Design Classes
• Package diagram
– A high-level diagram to associate classes of related groups.
– Separating or grouping objects based on
• certain characteristics (e.g. MVC) or
• in a distributed environment (e.g. client or server)
– Shows dependency relationships between each layers.
– This information can be captured by showing each layer as
a separate package.
Packaging the Design Classes
• Package diagram
– The classes are placed
inside the appropriate
package based on the
layer to which they
belong.
Packaging the Design Classes
• Dependency relationship.
– The arrow’s tail is connected to the package that is dependent,
– Arrowhead is connected to the independent package.
– To read a dependency relationship, read it in the direction of
the arrow.
– If one element changes (the independent element), the other
(dependent) element might also have to be changed.
• if a change is done in the independent element, need to
check how the change affect the dependent element.
– Dependency relationships can be between packages or
between classes within packages.
Summary
• Design process for sequence diagrams is the same as
communication diagrams.
• Primary benefit of the sequence diagram is the ability to lay
out the messages from top to bottom to emphasize the
sequence of firing.
• MVC is a good design pattern to support large and complex
system.
Summary
• Package diagram is a high-level diagram to associate classes of
related groups.
• It separates or grouping objects based on certain
characteristics (e.g. MVC) or in a distributed environment (e.g.
client or server)
• It shows dependency relationships between each layers.
• If one element changes (the independent element), the other
(dependent) element might also have to be changed.
• If a change is done in the independent element, need to
check how the change affect the dependent element.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 13
System Development Techniques
Diploma in Information Technology
Lesson 13
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Discuss on the bridging from analysis to
implementation
• Explain object-oriented architectural design
• Explain the object-oriented detailed design
Overview of Object-Oriented
Programs
• An object-oriented program
– consists of sets of computing objects.
– each object has data and program logic encapsulated
within itself.
– define the structure of the program logic and data fields by
defining a class.
– the class definition describes the structure or a template
of what an executing object looks like.
– from class we can instantiate object.
– instantiation of the class—making an instance (an object)
based on the template provided by the class definition.
Overview of Object-Oriented
Programs
• An object-oriented program
– consists of a set of these instantiated objects that
cooperate to accomplish a result.
– objects work together by sending each other messages
(calling methods) and working in concert to support the
functions of the main program.
Overview of Object-Oriented
Programs
• An object-oriented program
– Think of how people in a company from different department works
together to run the company.
• Department -> layer
(e.g. view, controller, model)
• People -> object
• People communicate with each other ->
object calling another object method.
Overview of Object-Oriented
Programs
• An object-oriented program example
• A window object that displays a
form
• User enters a student ID and other
information (message 1).
• After the student ID is entered, the
Window object sends a message
(message 2) to the Student class to
tell it to create a new Student
object (instance) in the program.
Overview of Object-Oriented
Programs
• An object-oriented program example
• The new Student object knows that it needs
more data for some of its attributes based
on internal logic in the student class,
• The Student object send a message to a
Database Access object asking for data from
the database (message 3).
• Once the Student object is completely
instantiated with all the required data, the
Student object sends the information back
to the Window object to display it on the
screen.
Overview of Object-Oriented
Programs
• An object-oriented program example
• The user then enters the updates to her
personal information (message 4), and
another sequence of messages is sent to
update the Student object in the program,
which forwards information to the
Database Access object and writes it to the
database.
Overview of Object-Oriented
Programs
• An object-oriented program
– consists of many objects.
– each object, consists of program logic exists in small segments called
methods.
– methods are “called” or invoked through messages
• Object calling methods of another object.
– there are three type of objects,
• “Three-layer architecture,”
– Window object (view layer),
– Student object (domain or business logic layer),
– Database Access object (data layer).
Analysis Models to Design Models
• To write a computer program, a programmer needs to know
– what the classes are, and
– what the methods are in those classes.
• The previous example is a single use case
– Update student information.
• A programmer will work on one use case at a time.
– select a use case and code the appropriate methods in the required
classes to carry out that use case.
• For programmer to perform the above task, the design
models must support that activity.
Analysis Models to Design Models
• For each use case, the design models must provide the
information required to
– identify the classes
– document the flow of execution (for coding of methods)
• Diagram below shows the model building process flows from
analysis to design to implementation
Introduction to the Design Models
• Design class diagram
– Primary model used to document the classes and the methods.
– Extension of the domain model class diagram that was developed
during analysis activities and requirements definition.
– The diagram shows a Student class both as the domain class and as
the design class.
Introduction to the Design Models
• To document the flow of execution of a particular use case,
use
– sequence diagram,
– a communication diagram,
– or CRC (class responsibility collaboration) cards.
• do not need to use all three for any given use case.
• Sequence diagrams and communication diagrams are
standard UML interaction diagrams.
• CRC cards are not standard UML, but are very popular for
designing simple system
Introduction to the Design Models
Sequence Diagram
• System sequence diagrams (SSD).
– In analysis phase
– Only two actors, the external actor and the system.
• Sequence diagram
– expands the system object to identify the internal
interacting objects.
Introduction to the Design Models
Sequence Diagram
• Sequence diagram
– a simple sequence diagram.
– System object is no longer included,
Introduction to the Design Models
Communication Diagram
• A communication diagram
– Provides basically the same information as sequence
diagram, but in different formats.
Introduction to the Design Models
CRC
• Class Responsibility Collaboration (CRC)
– Provides a straightforward approach for detailed object-
oriented design, especially for simple use cases.
– include a set of cards, with each card representing a class.
– each card identifies
• the class,
• its responsibilities (i.e., its methods), and
• the other classes with which it collaborates.
Introduction to the Design Models
CRC
• Class Responsibility Collaboration (CRC)
– Diagram shows both front and back sides of one single CRC card.
– The card represents a class.
– The list on the front left is the “responsibilities.”
– The list on the front right is the other classes with which this class
must “collaborate.”
– The list on the back is the attributes.
Steps of Object-Oriented Design
• Object-oriented design
– three separate layers: user interface, problem domain, and
database access layers.
– process that identifies and describes the classes within
each layer .
– defines the messages that are used to invoke the methods
of the involved classes.
• Object-oriented design is an analytical, rigorous, and detailed
process. Don’t be discouraged if it takes several tries before
you feel comfortable with this skill.
Steps of Object-Oriented Design
• Simple use cases
– at times it is easier just to code the use case, rather than develop a
formal use case design.
• If a model or diagram will assist in that objective, then it
should be created.
• If it does not contribute directly to the end result, then time
should not be spent on it.
• However, should not just skip modelling with the assumption
that a model is a distraction rather than a necessary step in
creating a solid design for the software.
Steps of Object-Oriented Design
• Steps required in
object-oriented
design
Steps of Object-Oriented Design
• In any of the three techniques for modelling, the objective is
to identify and define the methods that are required in each
class.
• The final design class diagram documents these required
methods.
• A package diagram is added to divide the classes into
components or subsystems that can be implemented as a
unit.
Design Classes and
the Design Class Diagram
• Design class diagram
– contains the final definition of each class in the final
object-oriented software system.
– primary source of information for this diagram is the
domain model.
• domain model
– shows a set of problem domain classes and their associations.
– serves as the basis for database design, and
– for the software classes as defined in the design class
diagram.
– done in analysis stage, generally don’t worry much about the
details of the attributes
Design Classes and
the Design Class Diagram
• Design class diagram
– In design stage, enhance the domain model
• attributes of a class must be declared as public or private and
• attribute must also be defined by its type, (e.g. String or numeric)
• define the methods and parameters that are passed to the
methods and the return values from methods.
Design Classes and
the Design Class Diagram
• Design class diagram
– As developers build the design class diagrams, they add many more
classes that were not originally defined in the domain model.
• Refer to previous Update student information, the Input window
objects and Database access objects are examples of additional
classes that are not problem domain classes.
• The classes in a system can be
partitioned into distinct
categories, such as user-interface
classes or data access classes.
(stereotyping)
• At times, designers may also
develop distinct class diagrams by
subsystem.
Design Class Stereotypes
• Stereotype
– a way to categorize a model element as a certain type.
– extends the basic definition of a model element by
indicating that it has some special characteristic to
highlight.
– notation for a stereotype : «control».
– four types of standard stereotypes:
• an entity class,
• a boundary or view class,
• a controller class, and
• a data access class.
Design Class Stereotypes
• Stereotype
Design Class Stereotypes
• Entity class
– design stereotype for a problem domain class.
– typically describes something users deal with when doing
their work.
– Objects of entity classes usually need to be remembered
– also referred to as persistent classes.
• The way to make data persistent is to write it to a file or database
so that it is saved and can be retrieved at a later execution of the
software.
Design Class Stereotypes
• Boundary or view class
– is specifically designed to live on the system’s automation
boundary.
– In a desktop system, these classes would be the windows
classes or Web pages and all the other classes associated
with the user interface.
– could also be a system interface between a company’s
system and an external system.
Design Class Stereotypes
• Controller class
– mediates between the boundary classes and the entity
classes.
– responsibility is to catch the messages from the boundary
class objects and send them to the correct entity class
objects.
– acts as a kind of switchboard between the boundary or
view layer and the domain layer.
Design Class Stereotypes
• Data access class
– is used to retrieve data from and send data to a database.
– also called a database access class.
– a separate layer of classes to access the database is often
included in the design.
– separate the insert database access logic, including SQL
statements, from the entity class.
Design Class Notation
• The format that analysts use to define each attribute
includes the following:
– Visibility
– Attribute-name
– Data-type-expression (return datatype)
– Initial-value
– Property
Design Class Notation
• Visibility
– denotes whether other objects can directly access
the attribute.
• + plus sign, public
• - minus sign, private
• # pound sign, protected
Design Class Notation
• Data-type-expression
– Return datatype
– such as character, string, integer, number, currency, or date
• Initial-value, if applicable
• Property (within curly braces), such as {key}, if
applicable
Design Class Notation
• Method signature
– shows all the information needed to invoke (or call) the
method.
– shows the format of the message that must be sent, which
consists of these attributes:
• Method visibility
• Method-name
• Method-parameter-list (incoming arguments)
• Return-type-expression (the type of the return parameter from
the method)
– Note some programming language (e.g. Java) does not include Return-
type-expression as method signature
Design Class Notation
Design Class Notation
• Domain model
– attribute list contains all attributes discovered during
analysis activities.
• Class diagram
– includes more information on attribute types, initial
values, and properties.
– include a stereotype for clarification.
• UML is meant to be a general object-oriented notation and
not specific to any one language. Thus, the notation won’t be
the same as programming method notation.
Design Class Notation
• Class-level method
– Static method in Java
– Refer to Student class, the
method called findAboveHours
(int hours): studentArray, which
is denoted with an underline.
• Class-level/Static method belongs
to the Class.
• Instant method (non underline)
belongs to each object.
Design Class Notation
• Generalization/specialization.
– inheritance
• Each of the three
subclasses inherits all the
attributes and methods of
the parent Sale class.
• Each subclass has a
saleID, a saleDate, and
so forth.
• Each subclass also has
additional attributes that
are unique to its own
specific class.
Design Class Notation
• class-level (static) attributes
• attribute that is
underlined,
Design Class Notation
• Abstract class
• Class name that is italic.
(e.g. Sale)
• a class that can never be
instantiated.
• To be inherited by other
class.
• Provides a central holding
place for all the attributes
and methods that each of
the three subclasses will
need
Developing the First-Cut Design
Class Diagram
• Developed by extending the
domain model class diagram.
• Requires two steps:
1. add type and initial value
information to the attributes
2. add navigation visibility
arrows.
Partial Sales subsystem domain model class diagram
Developing the First-Cut Design
Class Diagram
• Elaboration of Attributes
– fairly straightforward process.
– type information is determined by the designer, based on
his or her expertise.
– all attributes are kept public or private or protected.
– add a new compartment to each class for the addition of
method signatures.
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– ability of one object to interact with and send messages to
another object.
– Diagram shows “one-way” navigation visibility between
the Customer class and the Sale class.
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– “one-way” because Customer can interact with Sale, but
Sale does not have a direct reference back to Customer.
– navigation arrow indicates that a Sale object must be
visible to the Customer object.
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– Variable mySale in the Customer class refers to a Sale
instance.
– The mySale attribute is included in the example to provide
a way to actually implement it. (reference or pointer)
– think of it as having a Sale object embedded within the
Customer object.
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– database implementation
• do the reverse.
• put a foreign key of the Customer in the Sale data record to
capture the one-to-many relationship. (One customer has many
sales.)
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– Which classes need to have references to or be able to
access which other classes?
– General guidelines:
• One-to-many associations
– indicate a superior/subordinate relationship are usually
navigated from the superior to the subordinate
– for example, from Sale to SaleItem.
• Mandatory associations,
– objects in one class can’t exist without objects of another
class, are usually navigated from the independent class to the
dependent class—for example, from Customer to Sale.
Developing the First-Cut Design
Class Diagram
• Navigation Visibility
– General guidelines:
• When an object needs information from another
object, a navigation arrow might be required, pointing
either to the object itself or to its parent in a hierarchy.
• Navigation visibility arrows may be bidirectional—for
example, a Sale object might need to send a message
to its Customer object as well as the reverse.
Developing the First-Cut Design
Class Diagram
• Controller class:
– The very first step to do when creating the first-cut design
class diagram is to add a controller class.
– is a switchboard between the input screens and the
programming logic classes, i.e. the domain classes, for a
particular use case.
– always create a controller class for each use case, and
place it between the user-interface classes and the
problem domain classes.
– More details in next lesson.
• First cut class
diagram
Developing the First-Cut Design
Class Diagram
• First-cut Design Class Diagram
– add a controller class
• includes SaleHandler as the controller class.
• a controller class, or use case controller, is a utility class
that helps in the processing of a use case.
• has navigation visibility at the top of the visibility
hierarchy and starts the use case by messaging a
customer.
Developing the First-Cut Design
Class Diagram
• First-cut Design Class Diagram
– elaborate attributes
• add type information and visibility
– identify navigation visibility.
• first identify which classes may be involved and then
determine the classes that require navigation visibility
to other classes.
Developing the First-Cut Design
Class Diagram
• First-cut Design Class Diagram
– identify navigation visibility.
• price information is in the PromoOffering class
• description information is in the ProductItem class.
• In most instances, it is unnecessary to put the
navigation visibility reference attribute in the class. (this
information is implied by the arrow)
• the mySale attribute is redundant to the information
provided by the arrow. So, even though it was shown in
the previous diagram to emphasize the concept of
navigation visibility, it is left off in the previous and
subsequent figures.
Designing with CRC Cards
• Class Responsibility Collaboration (CRC)
– brainstorming and design technique for object-
oriented developers.
– use this technique during design to help identify
responsibilities of the class and the sets of classes
that collaborate for a particular use case.
Designing with CRC Cards
• CRD Card
– card with lines that partition it into three areas:
class name, responsibility, and collaboration
classes.
Designing with CRC Cards
• Process of developing a CRC model
– Before the design session, each team member
should have
• domain model class diagram
• list of use cases
• Other documents if available
– activity diagrams, system sequence diagrams, and use case
descriptions,
• stack of blank CRC-formatted index cards.
Designing with CRC Cards
• Process of developing a CRC model
– For each use case repeat these steps:
1. Select a use case.
• The first card to include should be a use case
controller card.
Designing with CRC Cards
2. Identify the first problem domain class that has
responsibility for this use case.
• This object will receive the first message from the use
case controller.
• Using the domain model that was developed during
analysis, select one class to take responsibility.
• Focus only on the problem domain classes.
• On the left side of the card, write the object’s
responsibility.
• For example, a Customer object may take responsibility
to make a new sale, so one responsibility may be Create
phone sale.
Designing with CRC Cards
3. Identify other classes that must collaborate with
the primary class to complete the use case.
• Do the above by identify the classes that have required
information or that need to be updated in this use case.
• Then go to the appropriate CRC card for that class and
write its responsibilities and attributes on the cards.
Designing with CRC Cards
4. Include the user-interface classes.
• Optional but helpful step.
• If some preliminary work has been done on the user-
interface requirements, it could be effective to add
CRC cards for all user-interface window classes that
are required for the use case.
• By including user-interface classes, all the input and
output forms can be included in the design, making it
much more complete.
Designing with CRC Cards
5. Add any other required utility classes that are
needed to the solution.
• For example, for a three-layer design, data access
classes will be part of the solution.
• Usually, each persistent domain class will have a data
access class to read and write to the database.
Designing with CRC Cards
• At the end of the process, we have a small set
of CRC cards that collaborate to support the
use case.
• The process can be enhanced by
– arranging the CRC cards on the table in the order
they are executed or called.
– That is the calling order can be determined at this
time. (for drawing of sequence diagram later)
Designing with CRC Cards
Create customer account Use Case
Designing with CRC Cards
Create customer account Use Case
Fundamental Principles for Good
Design
• Object responsibility
– Each object should be responsible for carrying out
a part of the system processing.
– Responsibilities are categorized in two major
areas:
• knowing
– what is an object expected to know?
• doing
– what is an object expected to do?
Fundamental Principles for Good
Design
• Object responsibility
– Knowing
• object’s responsibilities for knowing about
– its own data
– how to maintain the information in those attributes.
– where to go to get information when required.
– navigation visibility
– knowing about other classes with which it must collaborate to carry
out use cases.
Fundamental Principles for Good
Design
• Object responsibility
– Doing
• all the activities an object performs to complete a use
case.
• activities include
• receiving and processing messages.
• instantiate, or create, new objects that may be required for
completion of a use case.
• Classes must collaborate to carry out a use case, and some
classes are responsible for coordinating the collaboration.
Fundamental Principles for Good
Design
• Separation of responsibilities,
– aka separation of concerns,
– a design principle that is applied to a group of
classes rather than to each class individually.
– basic idea is to segregate classes into packages or
groupings based on a primary focus of processing
responsibility.
Fundamental Principles for Good
Design
• Separation of responsibilities
– fundamental principle behind multilayer design.
– multilayer design
• user-interface classes, business logic classes, and data access
classes.
• Each layer has a particular focus or area of responsibility.
– Classes that share the same focus or concern are grouped
together in a layer.
– This design principle allows flexibility in system
deployment because different layers, i.e., a grouping of
classes, can be located on different computers or at
different locations.
Fundamental Principles for Good
Design
• Protection from variations (change)
– parts of a system that are unlikely to change should be
segregated (or protected) from those that will change.
– try to isolate the parts that will change from those that are
more stable.
– Use multilayer design pattern.
• Decouple the user-interface logic from the business
logic.
• the user interface can be rewritten without affecting
the business logic.
– In other words, the business logic—being more stable—is
protected from variations in the user interface.
Fundamental Principles for Good
Design
• Indirection
– is the principle of separating two classes or other system
components by placing an intermediate class between
them to serve as a link.
– Don’t send a direct message from A to B. Let A send the
message to C and then let C forward it to B.
– Implemented using a Use case controller.
• The controller is a separate class that receives all the inputs and
directs it to the appropriate domain classes.
Fundamental Principles for Good
Design
• Coupling
– a qualitative measure of how closely the classes in a design
class diagram are linked.
– A simple way to think about coupling is by the number of
association relationships and whole/part relationships on
the design class diagram.
– Navigation visibility,
• measures what a class can link to and access.
– Low coupling is usually better for a system than high
coupling.
Fundamental Principles for Good
Design
• Cohesion
– the consistency of the functions within a single class and
– is a qualitative measure of its focus or unity of purpose.
– classes need to be highly cohesive to be well designed.
– That is one class only do one thing (and one thing good)
– Classes with low cohesion have several negative effects.
• hard to maintain because they perform many different functions,
• tend to be overly sensitive to changes within the system (ripple
effects).
• uually difficult to understand, their functions are intertwined and
their logic is complex.
Summary
• Design class diagram
– Primary model used to document the classes and the methods.
– Extension of the domain model class diagram that was developed
during analysis activities and requirements definition.
• To document the flow of execution of a particular use case,
use
– sequence diagram,
– a communication diagram,
– or CRC (class responsibility collaboration) cards.
Summary
• Class Responsibility Collaboration (CRC)
– brainstorming and design technique for object-oriented
developers.
– use this technique during design to help identify
responsibilities of the class and the sets of classes that
collaborate for a particular use case.
• Fundamental Principles for Good Design are:
– Object responsibility, Separation of responsibilities,
Protection from variations (change), Indirection, Low
Coupling and high Cohesion.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 12
System Development Techniques
Diploma in Information Technology
Lesson 3
Learning outcomes
After studying this chapter and the recommended reading, you should be able to:
Explain:
Use case description
Use cases and user goals
Use cases and event decomposition
Use cases diagrams
2
User Stories and Use Cases
Identifying user stories and use cases is a key task when defining functional requirements
User stories and use cases form the basis for the list of functions the system needs to carry out.
User Stories
One short sentence in user everyday language that states what a user does as part of their work.
Describes a goal the user has when using the system.
Focus on who, what, and why for each function.
The users and stakeholders are responsible for identifying the user stories.
User Stories
Objective is to get a potential user to articulate what the users wants to do with the new system.
The standard template for a user story looks like this:
“As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
User Stories
For example, some user stories for a bank teller might be:
“As a teller, I want to make a deposit to quickly serve more customers.”
“As a teller, I want to balance the cash drawer to assure there were no errors.”
As a customer of the bank using an ATM machine, some user stories might be:
“As a bank customer, I want to withdraw cash and feel confident the stack of cash I get is the correct amount.”
“As a bank customer, I want to deposit a check and feel confident the deposit is recorded correctly.”
User Stories – acceptance criteria
Final part of a user story is the acceptance criteria.
Indicate the features that must be present for the user to be satisfied with the resulting implementation.
Focus on functionality,
not on features or user-interface design.
User Stories – acceptance criteria
For example, the following are the acceptance criteria for the user story “bank teller making a deposit”:
Customer lookup must be by name or by account number.
It would be nice to display photo and signature of customer.
Any check hold requirements must be indicated.
Current balance and new balance must be displayed.
Use case
An activity the system performs in response to a request by a user.
User stories help analysts to identify and define use cases,
Two techniques to identify use cases:
user goal technique
event decomposition technique.
User Goal Technique
The user goal technique for identifying use cases includes these steps:
Identify all the potential users for the new system.
Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales).
Further classify potential users by organizational level (e.g., operational, management, executive).
User Goal Technique
Interview each type of user to determine the specific goals they will have when using the new system.
Start with goals they currently have and then get them to imagine innovative functions they think would add value.
Encourage them to state each goal in the imperative verb-noun form, such as Add customer, Update order, and Produce month-end report.
Create a list of preliminary use cases organized by type of user.
Look for duplicates with similar use case names and resolve inconsistencies.
Identify where different types of users need the same use cases.
Review the completed list with each type of user and then with interested stakeholders.
User Goal Technique
Event Decomposition
Most comprehensive technique for identifying use cases
The appropriate level of detail for identifying use cases is one that focuses on elementary business processes (EBPs)
EBP is a task that is performed by one person in one place in response to a business event.
Adds measurable business value, and leaves the system and its data in a stable and consistent state.
Event Decomposition
Examples of EBP
Search for item, Fill shopping cart, View product rating
Fill shopping cart
A response to the business event “Customer wants to shop.”
There is one person filling the cart.
Measurable value for the customer as items are added to the cart.
When customer stops adding items and moves to another task, the system remembers the current cart and is ready to switch to the new task.
Event Decomposition
Each EBP (and thus each use case) occurs in response to a business event.
An event
occurs at a specific time and place,
can be described,
remembered by the system.
drive or trigger all processing that a system does,
Listing and analysing events helps to define system requirements by identifying use cases.
Types of Events
Three types of events to consider:
external events,
temporal events (temporal – related to time)
state events (aka internal events).
External events
An event that occurs outside the system
Usually initiated by an external agent or actor
An external agent (or actor) is a person or organizational unit that supplies or receives data from the system.
To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system
External events
Example of an external agent is a customer.
customer may want to place an order for one or more products.
customer wants to return an ordered product
customer needs to pay the invoice for an order.
External events such as these define what the system needs to be able to do.
They are events that lead to important transactions that the system must process.
External events
Describing external events,
Name the event
clearly define the external agent/actor
description should include the action that the external agent wants to pursue.
Example
Event name: Customer places an order
Actor: a customer
Action: to place an order for some products
External events
External events can also come from the needs of people or organizational units inside the company (e.g., management requests for information).
Example
Event name: Management wants to check order status.
Actor: Management
Action: managers want to follow up on an order for a key customer
External events
External event can occurs when external entities provide new information that the system simply needs to store for later use.
Example,
Event name: Customer needs to update account information
Actor : customer
Action : customer reports a change in address, phone, or employer.
External events checklist
Checklist to help in identifying external events.
External events to look for include:
External agent wants something resulting in a transaction
External agent wants some information
Data changed and needs to be updated
Management wants some information
Temporal events
An event that occurs as a result of reaching a point in time.
Example:
Monthly payroll report
Weekly/monthly sales performance report
Exception reports.
Example, If a customer bill has not been paid within 15 days, the system might send a late notice.
The temporal event “Time to send late notice” might be defined as a point 15 days after the billing date.
Automatically generated
State events (internal events)
Event that occurs when something happens inside the system that triggers the need for processing.
For example,
Sale of a product results in an adjustment to an inventory record, and the inventory in stock drops below a reorder point, it is necessary to reorder.
The Sequence of Events:
Tracing a Transaction’s Life Cycle
A useful method for identifying events is to trace the sequence of events that might occur for a specific actor.
First, the customer wants a catalogue or asks for some information about item availability.
Then, the customer might want to place an order.
Perhaps the customer want to change the order—for example, correcting the size of the shirt or buying another shirt.
Next, the customer might want to check the status of an order to find out the shipping date.
Perhaps the customer has moved and wants an address change recorded for future catalogue mailings.
Finally, the customer might want to return an item.
Thinking through this type of sequence can help identify events
System controls
System controls
checks or safety procedures put in place to protect the integrity of the system.
For example,
logging on to a system is required because of system security controls
the integrity of the database, such as backing up the data every day
System controls
System controls are important to the system,
But spending time on system controls during analysis only adds details to the requirements model that users are not typically very concerned about; they trust the system developers to take care of such details.
One way to help decide which events apply to system controls is to assume that technology is perfect.
Perfect technology assumption
Events should be included during analysis only if the system would be required to respond under perfect conditions
Perfect conditions:
equipment never breaking down,
capacity for processing and storage being unlimited,
people operating the system being completely honest and never making mistakes
Perfect technology assumption
Examples of events that can be deferred until the developer is designing in system controls.
User wants to log on to the system
User wants to change the password
User wants to change preference settings
System crash requires database recovery
Time to back up the database
Time to require the user to change the password
Don’t worry much about these until you are considering design issues.
Event Decomposition
The event decomposition technique for identifying use cases includes these steps:
Consider the external events in the system environment that require a response from the system by using the external events checklist
For each external event, identify and name the use case that the system requires.
Event Decomposition
Consider the temporal events that require a response from the system by using the checklist shown in temporal event.
For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case.
Event Decomposition
Consider the state events that the system might respond to, particularly
if it is a real-time system in which devices or internal state changes trigger use cases.
For each state event, identify and name the use case that the system requires and then define the state change.
Event Decomposition
When events and use cases are defined, check to see if they are required as part of analysis by using the perfect technology assumption.
Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in as system controls.
Use Cases example
Sales Subsystem
Use cases Users/actors
Search for item Customer, customer service representative, store sales representative
View product comments and ratings Customer, customer service representative, store sales representative
View accessory combinations Customer, customer service representative, store sales representative
Fill shopping cart Customer
Empty shopping cart Customer
Check out shopping cart Customer
Fill reserve cart Customer
Empty reserve cart Customer
Convert reserve cart Customer
Create phone sale Customer service representative
Create store sale Store sales representative
Use Cases example
Order Fulfillment Subsystem
Use cases Users/actors
Ship items Shipping
Manage shippers Shipping
Create backorder Shipping
Create item return Shipping, customer
Look up order status Shipping, customer, management
Track shipment Shipping, customer, marketing
Rate and comment on product Customer
Provide suggestion Customer
Review suggestions Management
Use Cases example
Customer Account Subsystem
Use cases Users/actors
Create/update customer account Customer, customer service representative, store sales representative
Process account adjustment Management
Send message Customer
Browse messages Customer
Request friend linkup Customer
Reply to linkup request Customer
Send/receive partner credits Customer
View “mountain bucks” Customer
Transfer “mountain bucks” Customer
*mountain bucks are point system used by that company
Use Cases example
Marketing Subsystem
Use cases Users/actors
Add/update product information Merchandising, marketing
Add/update promotion Marketing
Add/update accessory package Merchandising
Add/update business partner link Marketing
Use Cases example
Reporting Subsystem
Use cases Users/actors
Produce daily transaction summary report Management
Produce sales history report Management, marketing
Produce sales trends report Marketing
Produce customer usage report Marketing
Produce shipment history report Management, shipping
Produce promotion impact report Marketing
Produce promotional partner activity report Management, marketing
Use case diagram
Create diagrams that visually depict use cases and how they are organized.
The use case diagram is the Unified Modelling Language (UML) model used to illustrate use cases and their relationship to users.
Actors
In Unified Modelling Language (UML) an actor is a person who uses the system .
An actor is always outside the automation boundary of the system but may be part of the manual portion of the system.
Sometimes, the actor for a use case is not a person; instead, it can be another system or device that receives services from the system.
A simple stick figure represents an actor.
Use case diagram basic
Use case diagram basic
The stick figure is given a name that characterizes the role the actor is playing.
The use case itself is represented by an oval with the name of the use case inside.
Use case diagram basic
The connecting line between the actor and the use case indicates that the actor is involved with that use case.
Use case diagram basic
The automation boundary, which defines the border between the computerized portion of the application and the people operating the application, is shown as a rectangle containing the use case.
Use case diagram examples
Use case diagram examples
Many ways to organize use case diagrams for communicating with users, stakeholders, and project team members.
One way is to show all use cases invoked by a particular actor (i.e., from the user’s viewpoint).
This approach is often used during requirements definition because the systems analyst may be working with a particular user and identifying all the functions that user performs with the system.
The next Use case diagram illustrates this viewpoint, showing all the use cases involving the customer for the Sales subsystem.
Use case diagram examples
Use case diagram examples
The next use case diagram shows use cases involving the customer service representative and the store sales representative for the Sales subsystem.
Analysts can expand this approach to include all the use cases invoked by any department, regardless of the subsystem, or all use cases important to a specific stakeholder.
Use case diagram examples
Use case diagram examples
«includes» Relationships
During the development of a use case diagram, it becomes apparent that one use case might use the services of another use case.
For example, in the Sales subsystem use case the customer might search for an item, view product comments and ratings, and view accessory combinations before beginning to fill the shopping cart.
However, while filling the shopping cart, the customer might also search for an item, view product comments, and view accessories. Therefore, one use case uses, or “includes,” another use case.
Use case diagram examples
«includes» Relationships
Use case diagram examples
«includes» Relationships
Fill shopping cart also includes Search for item, View product comments and ratings, and View accessory combinations.
Thus, the Customer can view comments initially, and also while carrying out the Fill shopping cart use case.
The relationship is read Fill shopping cart includes Search for item.
Use case diagram examples
«includes» Relationships
Also know as «uses» relationship.
Note that the word includes is enclosed within guillemets in the diagram; this is the way to refer to a stereotype in UML. It means that the relationship between one use case and another use case is a stereotypical «includes» relationship.
Developing a Use Case Diagram
The steps to develop use case diagrams are:
Identify all the stakeholders and users who would benefit by having a use case diagram.
Determine what each stakeholder or user needs to review in a use case diagram. Typically, a use case diagram might be produced for each subsystem, for each type of user, for use cases with the «includes» relationship, and for use cases that are of interest to specific stakeholders.
Developing a Use Case Diagram
For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams.
Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users.
Summary
Objective of user story is to get a potential user to articulate what the users wants to do with the new system.
The standard template for a user story looks like this:
“As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
Summary
Two techniques to identify use cases:
user goal technique
event decomposition technique.
Three types of events to consider for event decomposition technique
external events,
temporal events (temporal – related to time)
state events (aka internal events).
Summary
Use case diagrams visually depict use cases and how they are organized.
The use case diagram is the Unified Modelling Language (UML) model used to illustrate use cases and their relationship to users.
Read
Textbook:
Satzinger, Robert & Stephen Chapter 3
59
System Development Techniques
Diploma in Information Technology
Lesson 6
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Explain the use case descriptions
• Discuss the activity diagrams for use cases
• Describe design system inputs and outputs
• Discuss the system sequence diagram
• Explain the Use cases and CRUD
• Describe the integrating requirements models
Use Case Descriptions
• A list of use cases and use case diagrams
provides an overview of all the use cases for a
system.
• Detailed information about each use case is
described with a use case description.
Use Case Descriptions
• Use case descriptions tend to be written at two separate
levels of detail: brief description and fully developed
description.
• A brief description
– enough detail for very simple use cases, especially when the system to
be developed is a small, well-understood application.
– Examples of simple use cases are Add product comment or Send
message.
• A use case such as Fill shopping cart is complex enough that a
fully developed description is also written after the initial brief
use case description is finalized.
Use Case Descriptions
• Use cases and brief use case descriptions
Use Case Descriptions
• The fully developed description is the most
formal method for documenting a use case.
• To create a comprehensive, robust system that
truly meets users’ needs, must understand the
detailed steps of each use case.
Use Case Descriptions
• No standard format. Many different format.
• Common items in a Use case description
– Use case name
– Scenario
– Triggering event
– Brief description
– Actors
– Related use cases
– Stakeholders
– Preconditions, Postconditions
– Flow of Activities
– Exception conditions
– Etc.
Use Case Descriptions
Fully developed
description
sample
Use Case Descriptions
Fully developed
description
sample
Use Case Descriptions
• Scenarios (aka use case instances)
– ONE flow of activity is ONE scenario.
– The use case Create customer account will have a separate
flow of activities depending on which actor invokes the use
case.
– The processes for a customer service representative
updating information over the phone might be quite
different from the processes for a customer updating the
information him or herself.
– Another use case description would be written for the
Create customer account by phone scenario.
Use Case Descriptions
• Preconditions
– identify what the state of the system must be for
the use case to begin,
– including what objects must already exist,
– what information must be available, and even the
condition of the actor prior to beginning the use
case.
Use Case Descriptions
• Postconditions
– identify what must be true upon completion of the use
case.
– indicate what new objects are created or updated by the
use case and how objects need to be associated.
– For example, in the Create customer account use case, it is
important to test that a customer record, address record,
and account record were successfully added to the
database.
Use Case Descriptions
• Flow of activities
– identifying the steps performed by the actor and
the responses required by the system.
• Alternative activities and exception conditions
– The numbering of exception conditions also helps
tie the exceptions to specific steps in the flow of
activities.
Activity Diagrams for Use Cases
• In previous you learned about activity
diagrams as a form of workflow diagram that
might cover several use cases.
• Activity diagrams are also used to document
the flow of activities for one use case.
• Provides a more graphical view of the flow of
activities.
Activity Diagrams for Use Cases
• Activity diagram for
Create customer
account
Activity Diagrams for Use Cases
• Activity diagram for
Ship Items use case
Activity Diagrams for Use Cases
• Activity diagram for
Fill shopping cart
• Activity diagrams
are helpful when the
flow of activities for
a use case is
complex.
• Three use cases:
– Search for Product,
– Look at product
reviews,
– Search and view
accessories
Activity Diagrams for Use Cases
• Use case Fill shopping cart
– three other use cases (Search for Product, Look at product
reviews, Search and view accessories) might be invoked
while adding items to the shopping cart.
• The actor might search for a product and then look
at product reviews before adding the item to the
cart.
• Once an item is added, the actor might search for
and view available accessories and then add one or
more to the cart.
The System Sequence Diagram
• Object-oriented approach,
– flow of information is achieved through sending messages
• to and from actors
• back and forth between internal objects.
• A system sequence diagram (SSD)
– describe flow of information into and out of the automated portion of
the system.
– documents the inputs and the outputs and identifies the interaction
between actors and the system.
– effective tool to help in the initial design of the user interface by
identifying the specific information that flows from the user into the
system and the information that flows out of the system back to the
user.
The System Sequence Diagram
• Generic system sequence diagram (SSD)
SSD Notation
• Stick figure represents an actor
– In use case diagram, the actor “uses” the system,
– SSD is on how the actor “interacts” with the system by
entering input data and receiving output data.
• The box labeled :System is an object that represents
the entire automated system.
• SSD (and all other interaction diagrams), use object
notation instead of class notation.
– object notation, a rectangle with the name of the object
underlined.
SSD Notation
• Underneath the actor and :System are vertical
dashed lines called lifelines.
• A lifeline, or object lifeline, is simply the ”life
time” of that object or during the use case.
SSD Notation
• The arrows between the lifelines represent the
messages that are sent by the actor.
• The sequence of messages is read from top to
bottom in the diagram.
• A message
– labeled to describe its
purpose and any input data
being sent.
– name should follow the
verb-noun syntax to make
the purpose clear.
SSD Notation
• Returned value
– A dashed arrow indicates a response or an answer
(in programming, a return),
– immediately follows the initiating message.
– it is a response, only the data that are sent on the
response are noted.
SSD Notation
• A note can be added to any UML diagram to
add explanations.
SSD Notation
• Frequently, the same message is sent multiple times in a loop,
– For example, when an actor enters items on an order, the message to
add an item to an order may be sent multiple times.
– The message and its return are located inside a larger rectangle called
a loop frame.
SSD Notation
• Alternate notation for loop
– [true/false condition] return-value := message-name
(parameter-list)
– The asterisk (*) preceding the true/false condition
indicates that the message repeats as long as the
true/false condition evaluates to true.
SSD Notation
• The opt frame is used when a message or a series of
messages is optional or based on some true/false
condition.
SSD Notation
• The alt frame is used with if-then-else logic.
Developing a System Sequence
Diagram (SSD)
• An SSD is used in conjunction with the use
case descriptions to help document the details
of a single use case or scenario within a use
case.
• To develop an SSD, it is useful to have a
detailed description of the use case—either in
the fully developed form or as an activity
diagram.
Developing a System Sequence
Diagram (SSD)
• An SSD is used in conjunction with the use case
descriptions to help document the details of a single
use case or scenario within a use case.
• SSD provide explicit identification of inputs and
outputs.
• Easy to identify when an input or output occurs in
SSD.
– Inputs and outputs occur whenever an arrow in an activity
diagram goes from an external actor to the computer
system.
Developing a System Sequence
Diagram (SSD)
• Development steps of SSD
1. Identify the input messages
2. Describe the message from the external actor to
the system by using the message notation
described earlier.
3. Identify and add any special conditions on the
input messages, including iteration and
true/false conditions.
4. Identify and add the output return messages.
Developing a System Sequence
Diagram (SSD)
1. Identify the input
messages
• Three locations with a
workflow arrow crossing the
boundary line between the
customer and the system.
• At each location that the
workflow crosses the
automation boundary, input
data are required;
therefore, a message is
needed.
Developing a System Sequence
Diagram (SSD)
2. Describe the message from the external actor to the
system by using the message notation described earlier.
• The names of the messages reflect
the services that the actor is
requesting of the system:
createNewCustomer, enterAddress,
and enterCreditCard.
• Instead of enterAddress, the name
could be createAddress. The point to
remember is that the message name
should describe the service
requested from the system and
should be in verb-noun form.
Developing a System Sequence
Diagram (SSD)
3. Identify and add any special conditions on the input
messages, including iteration and true/false conditions.
• The enterAddress
message is repeated
for each address
needed for the
customer.
• The asterisk symbol in
front of the message
is shown
Developing a System Sequence
Diagram (SSD)
4. Identify and add the output return messages.
• Two options for showing
return information:
• as a return value on
the message itself
• as a separate return
message with a dashed
arrow.
• Return messages are each
named with a noun that
indicates what is being
returned.
• Sometimes, no output data
are returned.
Developing a System Sequence
Diagram (SSD)
• The objective of developing SSD is to discover and
understand user requirements
• Analyst should be working closely with users to
define exactly how the workflow proceeds and
exactly what information needs to be passed in and
provided as output.
• This is an iterative process, and analyst will probably
need to refine these diagrams several times before
they accurately reflect the needs of the users.
Use Cases and CRUD
Create, Read/Report, Update and Delete
• Technique to validate use cases
• Involves verifying that all of the needed use cases
have been identified to maintain the data
represented by the domain model class diagram.
• To validate and refine use cases, the analyst looks at
each type of data and verifies that use cases have
been identified that create the data, read or report
on the data, update the data, and delete (or archive)
the data.
Use Cases and CRUD
Create, Read/Report, Update and Delete
• Take already identified use cases and verify that
there are use cases for create, read, update, and
delete as a cross-check.
Use Cases and CRUD
Create, Read/Report, Update and Delete
• Another use
– summarize all use cases and all data entities/domain classes to show
the connection between use cases and data.
CRUD table showing use cases and corresponding domain classes
Use Cases and CRUD
Create, Read/Report, Update and Delete
• For example,
– the use case Create customer account actually creates customer data
and account data, so the C is included in those two cells.
– The use case Process account adjustment reads information about the
sale, reads information about the customer, updates the account, and
creates an adjustment.
Use Cases and CRUD
Create, Read/Report, Update and Delete
• Based table, there are insufficient use cases to cover the Sale
and the Adjustment domain classes.
– The Sale class will need to have additional use cases to create, update, and
delete Sale objects. I
– The Adjustment class will require use cases to update, report, and delete
Adjustment objects.
Use Cases and CRUD
Create, Read/Report, Update and Delete
• The CRUD technique for validating and refining use cases
includes these steps:
1. Identify all the domain classes involved in the new system.
2. For each type of data (domain class), verify that a use case has been
identified that creates a new instance, updates existing instances,
reads or reports values of instances, and deletes (or archives) an
instance.
3. If a needed use case has been overlooked, add a new use case and
then identify the stakeholders.
4. With integrated applications, make sure it is clear which application is
responsible for adding and maintaining the data and which system
merely uses the data.
Integrating Requirements Models
• Iterative approach
– only construct the diagrams that are necessary for a given iteration.
• Complete use case diagram to get an idea of the total scope of
the new system.
– the supporting details included in use case descriptions, activity
diagrams, and system sequence diagrams need only be done for use
cases in the specific iteration
• Not all use cases need to be modeled in detail.
Integrating Requirements Models
• The domain model class diagram should be as complete as
possible for the entire system early in the project.
• Refinement and actual implementation of many classes will
wait for later iterations, but the domain model should be
fairly complete.
• The domain model is necessary to identify all the domain
classes that are required in the new system.
• The domain model is also used to design the database.
Integrating Requirements Models
• Construction of a diagram depends on information provided
by another diagram.
• Development of a new diagram often helps refine and correct
a previous diagram.
Relationships among object-oriented requirements models
Integrating Requirements Models
• The solid arrows represent major dependencies.
• The dashed arrows show minor dependencies.
• The dependencies generally flow from top to bottom, but
some arrows have two heads to illustrate that influence goes
in both directions.
Integrating Requirements Models
• Development of detailed diagrams is critical to gain a
thorough understanding of the user requirements.
– The use case diagram, use case description and Activity diagrams used
to capture the processes of the new system.
– The class diagram and its dependent diagrams capture information
about the classes for the new system.
Integrating Requirements Models
• The use case diagram and the domain model
class diagram are the primary models from
which others draw information.
• Should develop those two diagrams as
completely as possible.
Integrating Requirements Models
• The detailed descriptions either in Use case description or in
activity diagrams,
– provide important internal documentation of the use cases
– must completely support the use case diagram.
– are important for development of system sequence diagrams.
• The detailed descriptions, activity diagrams, and system
sequence diagrams must all be consistent with regard to the
steps of a particular use case.
• Understanding the relationships among these models is an
important element in the quality of the models.
Summary
• Use cases and use case diagrams provides an
overview of all the use cases for a system.
• Detailed information about each use case is
described with a use case description.
• Use case descriptions tend to be written at
two separate levels of detail: brief description
and fully developed description.
Summary
• Activity diagrams are also used to document the flow
of activities for one use case.
• Provides a more graphical view of the flow of
activities.
• A system sequence diagram (SSD)
– describe flow of information into and out of the
automated portion of the system.
– documents the inputs and the outputs and identifies the
interaction between actors and the system.
Summary
• CRUD technique is to validate use cases
• CRUD Involves verifying that all of the needed
use cases have been identified to maintain the
data represented by the domain model class
diagram.
Summary
• The detailed descriptions, activity diagrams,
and system sequence diagrams must all be
consistent with regard to the steps of a
particular use case.
• Understanding the relationships among these
models is an important element in the quality
of the models.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 5
System Development Techniques
Diploma in Information Technology
Lesson 3
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Explain:
• Use case description
• Use cases and user goals
• Use cases and event decomposition
• Use cases diagrams
User Stories and Use Cases
• Identifying user stories and use cases is a key
task when defining functional requirements
• User stories and use cases form the basis for
the list of functions the system needs to carry
out.
User Stories
• One short sentence in user everyday language that
states what a user does as part of their work.
• Describes a goal the user has when using the system.
• Focus on who, what, and why for each function.
• The users and stakeholders are responsible for
identifying the user stories.
User Stories
• Objective is to get a potential user to
articulate what the users wants to do with the
new system.
• The standard template for a user story looks
like this:
• “As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
User Stories
• For example, some user stories for a bank teller
might be:
– “As a teller, I want to make a deposit to quickly serve more customers.”
– “As a teller, I want to balance the cash drawer to assure there were no
errors.”
• As a customer of the bank using an ATM machine,
some user stories might be:
– “As a bank customer, I want to withdraw cash and feel confident the
stack of cash I get is the correct amount.”
– “As a bank customer, I want to deposit a check and feel confident the
deposit is recorded correctly.”
User Stories – acceptance criteria
• Final part of a user story is the acceptance
criteria.
– Indicate the features that must be present for the
user to be satisfied with the resulting
implementation.
– Focus on functionality,
• not on features or user-interface design.
User Stories – acceptance criteria
• For example, the following are the acceptance
criteria for the user story “bank teller making
a deposit”:
– Customer lookup must be by name or by account number.
– It would be nice to display photo and signature of
customer.
– Any check hold requirements must be indicated.
– Current balance and new balance must be displayed.
Use case
• An activity the system performs in response to
a request by a user.
• User stories help analysts to identify and
define use cases,
• Two techniques to identify use cases:
– user goal technique
– event decomposition technique.
User Goal Technique
• The user goal technique for identifying use
cases includes these steps:
1. Identify all the potential users for the new
system.
2. Classify the potential users in terms of their
functional role (e.g., shipping, marketing, sales).
3. Further classify potential users by organizational
level (e.g., operational, management, executive).
User Goal Technique
4. Interview each type of user to determine the specific goals they
will have when using the new system.
– Start with goals they currently have and then get them to
imagine innovative functions they think would add value.
– Encourage them to state each goal in the imperative verb-noun
form, such as Add customer, Update order, and Produce
month-end report.
5. Create a list of preliminary use cases organized by type of user.
6. Look for duplicates with similar use case names and resolve
inconsistencies.
7. Identify where different types of users need the same use cases.
8. Review the completed list with each type of user and then with
interested stakeholders.
User Goal Technique
Event Decomposition
• Most comprehensive technique for identifying use
cases
• The appropriate level of detail for identifying use
cases is one that focuses on elementary business
processes (EBPs)
– EBP is a task that is performed by one person in one place
in response to a business event.
– Adds measurable business value, and leaves the system
and its data in a stable and consistent state.
Event Decomposition
• Examples of EBP
– Search for item, Fill shopping cart, View product rating
• Fill shopping cart
– A response to the business event “Customer wants to shop.”
– There is one person filling the cart.
– Measurable value for the customer as items are added to the cart.
– When customer stops adding items and moves to another task, the
system remembers the current cart and is ready to switch to the new
task.
Event Decomposition
• Each EBP (and thus each use case) occurs in response
to a business event.
• An event
– occurs at a specific time and place,
– can be described,
– remembered by the system.
– drive or trigger all processing that a system does,
• Listing and analysing events helps to define system
requirements by identifying use cases.
Types of Events
• Three types of events to consider:
– external events,
– temporal events (temporal – related to time)
– state events (aka internal events).
External events
• An event that occurs outside the system
• Usually initiated by an external agent or actor
• An external agent (or actor) is a person or
organizational unit that supplies or receives
data from the system.
• To identify the key external events, the
analyst first tries to identify all the external
agents that might want something from the
system
External events
• Example of an external agent is a customer.
– customer may want to place an order for one or more
products.
– customer wants to return an ordered product
– customer needs to pay the invoice for an order.
• External events such as these define what the system
needs to be able to do.
• They are events that lead to important transactions
that the system must process.
External events
• Describing external events,
– Name the event
– clearly define the external agent/actor
– description should include the action that the
external agent wants to pursue.
• Example
– Event name: Customer places an order
– Actor: a customer
– Action: to place an order for some products
External events
• External events can also come from the needs of
people or organizational units inside the company
(e.g., management requests for information).
• Example
– Event name: Management wants to check order status.
– Actor: Management
– Action: managers want to follow up on an order for a key
customer
External events
• External event can occurs when external
entities provide new information that the
system simply needs to store for later use.
• Example,
– Event name: Customer needs to update account
information
– Actor : customer
– Action : customer reports a change in address,
phone, or employer.
External events checklist
• Checklist to help in identifying external events.
• External events to look for include:
– External agent wants something resulting in a
transaction
– External agent wants some information
– Data changed and needs to be updated
– Management wants some information
Temporal events
• An event that occurs as a result of reaching a point in
time.
• Example:
– Monthly payroll report
– Weekly/monthly sales performance report
– Exception reports.
• Example, If a customer bill has not been paid within 15 days, the
system might send a late notice.
• The temporal event “Time to send late notice” might be defined as
a point 15 days after the billing date.
• Automatically generated
State events (internal events)
• Event that occurs when something happens
inside the system that triggers the need for
processing.
• For example,
– Sale of a product results in an adjustment to an
inventory record, and the inventory in stock drops
below a reorder point, it is necessary to reorder.
The Sequence of Events:
Tracing a Transaction’s Life Cycle
• A useful method for identifying events is to trace the
sequence of events that might occur for a specific actor.
– First, the customer wants a catalogue or asks for some information about item
availability.
– Then, the customer might want to place an order.
– Perhaps the customer want to change the order—for example, correcting the
size of the shirt or buying another shirt.
– Next, the customer might want to check the status of an order to find out the
shipping date.
– Perhaps the customer has moved and wants an address change recorded for
future catalogue mailings.
– Finally, the customer might want to return an item.
• Thinking through this type of sequence can help identify
events
System controls
• System controls
– checks or safety procedures put in place to protect
the integrity of the system.
– For example,
• logging on to a system is required because of system
security controls
• the integrity of the database, such as backing up the
data every day
System controls
• System controls are important to the system,
• But spending time on system controls during
analysis only adds details to the requirements
model that users are not typically very
concerned about; they trust the system
developers to take care of such details.
• One way to help decide which events apply to
system controls is to assume that technology
is perfect.
Perfect technology assumption
• Events should be included during analysis only
if the system would be required to respond
under perfect conditions
• Perfect conditions:
– equipment never breaking down,
– capacity for processing and storage being
unlimited,
– people operating the system being completely
honest and never making mistakes
Perfect technology assumption
• Examples of events that can be deferred until the
developer is designing in system controls.
– User wants to log on to the system
– User wants to change the password
– User wants to change preference settings
– System crash requires database recovery
– Time to back up the database
– Time to require the user to change the password
• Don’t worry much about these until you are
considering design issues.
Event Decomposition
• The event decomposition technique for
identifying use cases includes these steps:
1. Consider the external events in the system
environment that require a response from the
system by using the external events checklist
2. For each external event, identify and name the
use case that the system requires.
Event Decomposition
3. Consider the temporal events that require a
response from the system by using the
checklist shown in temporal event.
4. For each temporal event, identify and name
the use case that the system requires and
then establish the point of time that will
trigger the use case.
Event Decomposition
5. Consider the state events that the system
might respond to, particularly
if it is a real-time system in which devices or
internal state changes trigger use cases.
6. For each state event, identify and name the
use case that the system requires and then
define the state change.
Event Decomposition
• When events and use cases are defined, check
to see if they are required as part of analysis
by using the perfect technology assumption.
– Do not include events that involve such system
controls as login, logout, change password, and
backup or restore the database, as these are put
in as system controls.
Use Cases example
Sales Subsystem
Use cases Users/actors
Search for item
Customer, customer service
representative, store sales
representative
View product comments and ratings
Customer, customer service
representative, store sales
representative
View accessory combinations
Customer, customer service
representative, store sales
representative
Fill shopping cart Customer
Empty shopping cart Customer
Check out shopping cart Customer
Fill reserve cart Customer
Empty reserve cart Customer
Convert reserve cart Customer
Create phone sale Customer service representative
Create store sale Store sales representative
Use Cases example
Order Fulfillment Subsystem
Use cases Users/actors
Ship items Shipping
Manage shippers Shipping
Create backorder Shipping
Create item return Shipping, customer
Look up order status
Shipping, customer,
management
Track shipment Shipping, customer, marketing
Rate and comment on product Customer
Provide suggestion Customer
Review suggestions Management
Use Cases example
Customer Account Subsystem
Use cases Users/actors
Create/update customer account
Customer, customer service
representative, store sales
representative
Process account adjustment Management
Send message Customer
Browse messages Customer
Request friend linkup Customer
Reply to linkup request Customer
Send/receive partner credits Customer
View “mountain bucks” Customer
Transfer “mountain bucks” Customer
*mountain bucks are point system used by that company
Use Cases example
Marketing Subsystem
Use cases Users/actors
Add/update product
information
Merchandising, marketing
Add/update promotion Marketing
Add/update accessory package Merchandising
Add/update business partner
link
Marketing
Use Cases example
Reporting Subsystem
Use cases Users/actors
Produce daily transaction summary report Management
Produce sales history report Management, marketing
Produce sales trends report Marketing
Produce customer usage report Marketing
Produce shipment history report Management, shipping
Produce promotion impact report Marketing
Produce promotional partner activity report Management, marketing
Use case diagram
• Create diagrams that visually depict use cases
and how they are organized.
• The use case diagram is the Unified Modelling
Language (UML) model used to illustrate use
cases and their relationship to users.
Actors
• In Unified Modelling Language (UML) an actor is a
person who uses the system .
• An actor is always outside the automation boundary
of the system but may be part of the manual portion
of the system.
• Sometimes, the actor for a use case is not a person;
instead, it can be another system or device that
receives services from the system.
• A simple stick figure represents an actor.
Use case diagram basic
Use case diagram basic
• The stick figure is given a name that
characterizes the role the actor is playing.
• The use case itself is represented by an oval
with the name of the use case inside.
Use case diagram basic
• The connecting line between the actor and
the use case indicates that the actor is
involved with that use case.
Use case diagram basic
• The automation boundary, which defines the
border between the computerized portion of the
application and the people operating the
application, is shown as a rectangle containing the
use case.
Use case diagram examples
Use case diagram examples
• Many ways to organize use case diagrams for communicating
with users, stakeholders, and project team members.
• One way is to show all use cases invoked by a particular actor
(i.e., from the user’s viewpoint).
• This approach is often used during requirements definition
because the systems analyst may be working with a particular
user and identifying all the functions that user performs with
the system.
• The next Use case diagram illustrates this viewpoint, showing
all the use cases involving the customer for the Sales
subsystem.
Use case diagram examples
Use case diagram examples
• The next use case diagram shows use cases
involving the customer service representative
and the store sales representative for the
Sales subsystem.
• Analysts can expand this approach to include
all the use cases invoked by any department,
regardless of the subsystem, or all use cases
important to a specific stakeholder.
Use case diagram examples
Use case diagram examples
«includes» Relationships
• During the development of a use case diagram, it becomes
apparent that one use case might use the services of another
use case.
• For example, in the Sales subsystem use case the customer
might search for an item, view product comments and ratings,
and view accessory combinations before beginning to fill the
shopping cart.
• However, while filling the shopping cart, the customer might
also search for an item, view product comments, and view
accessories. Therefore, one use case uses, or “includes,”
another use case.
Use case diagram examples
«includes» Relationships
Use case diagram examples
«includes» Relationships
• Fill shopping cart also includes Search for item, View
product comments and ratings, and View accessory
combinations.
• Thus, the Customer can view comments initially, and
also while carrying out the Fill shopping cart use
case.
• The relationship is read Fill shopping cart includes
Search for item.
Use case diagram examples
«includes» Relationships
• Also know as «uses» relationship.
• Note that the word includes is enclosed within
guillemets in the diagram; this is the way to refer to a
stereotype in UML. It means that the relationship
between one use case and another use case is a
stereotypical «includes» relationship.
Developing a Use Case Diagram
• The steps to develop use case diagrams are:
1. Identify all the stakeholders and users who would benefit
by having a use case diagram.
2. Determine what each stakeholder or user needs to
review in a use case diagram. Typically, a use case
diagram might be produced for each subsystem, for each
type of user, for use cases with the «includes»
relationship, and for use cases that are of interest to
specific stakeholders.
Developing a Use Case Diagram
3. For each potential communication need, select the
use cases and actors to show and draw the use case
diagram. There are many software packages that
can be used to draw use case diagrams.
4. Carefully name each use case diagram and then
note how and when the diagram should be used to
review use cases with stakeholders and users.
Summary
• Objective of user story is to get a potential
user to articulate what the users wants to do
with the new system.
• The standard template for a user story looks
like this:
• “As a <role played>, I want to <goal or desire>
so that <reason or benefit>.”
Summary
• Two techniques to identify use cases:
– user goal technique
– event decomposition technique.
• Three types of events to consider for event
decomposition technique
– external events,
– temporal events (temporal – related to time)
– state events (aka internal events).
Summary
• Use case diagrams visually depict use cases
and how they are organized.
• The use case diagram is the Unified Modelling
Language (UML) model used to illustrate use
cases and their relationship to users.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 3
System Development Techniques
Diploma in Information Technology
Lesson 4
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Draw use cases using StarUML™
• UML diagramming
• Use case diagram
• Activity diagram
• Class diagram
• State machine diagram
• Conceptual model
• Sequence diagram
StarUML™
• A software modeling platform that supports
UML (Unified Modeling Language).
• Based on UML version 1.4 and provides eleven
different types of diagram, and it accepts UML
2.0 notation.
• One of the popular opensource leading
software modeling tools.
StarUML™
• Download at https://staruml.io/
https://staruml.io/
StarUML™ Use Case Diagram
• Model->Add Diagram->Use Case Diagram.
• An empty diagram and a tool box with Use
Case elements will be available.
StarUML™ Use Case Diagram
• Draw the three Use case diagram using
StarUML ™.
Use case diagram examples
Use case diagram examples
Use case diagram examples
«includes» Relationships
Activity diagram
• Draw the three Activity diagram using
StarUML ™.
Activity diagram
Activity
diagram
Activity diagram
Domain Model Class diagram
• Draw the three Domain Model Class diagram
using StarUML ™.
Domain Model Class diagram
Domain Model Class diagram
Domain Model Class diagram
State Machine Diagram
• Draw the two State Machine diagram using
StarUML ™.
State Machine Diagram
State Machine Diagram
Sequence Diagram
• Draw the Sequence diagram using StarUML ™.
Summary
• StarUML™ is a software modeling platform that supports UML
(Unified Modeling Language) drawing.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 3
StarUMLTM
• https://staruml.io/
https://staruml.io/
System Development Techniques
Diploma in Information Technology
Lesson 5
Learning outcomes
After studying this chapter and the recommended reading, you
should be able to:
• Understand conceptual model
• Discuss class, association focusing on
generalisation, composition and aggregation
• Describe the extending requirements models
• Discuss the state machine diagram
Domain classes (data entities)
• “Things” end users deal with when they do their
work
– E.g. products, sales, shippers, shipments, and customers.
• Information systems need to store information about
customers and products, so it is important for the
analyst to identify all the important information
about them.
• Techniques to identify domain class or data entity:
– brainstorming technique and
– the noun technique.
The Brainstorming Technique
• Analyst ask the users to discuss the types of
“things” they work with routinely.
• Different types of “things” are important to
different users, so it is important to involve all
types of users to help identify problem
domain things.
The Brainstorming Technique
• Steps:
1. Identify a user and a set of use cases or user
stories.
2. Brainstorm with the user to identify “things”
involved when carrying out the use case—that
is, “things” about which information should be
captured by the system.
The Brainstorming Technique
3. Use the types of “things” (categories) to
systematically ask questions about potential
“things”, such as the following:
• Are there any tangible things you store information
about? Are there any locations involved? Are there
roles played by people that you need to remember?
4. Continue to work with all types of users and
stakeholders to expand the brainstorming list.
5. Merge the results, eliminate any duplicates, and
compile an initial list.
The Brainstorming Technique
• Brainstorming technique
The Noun Technique
• A noun is a person, place, or thing.
• Identifying nouns help to identify what needs
to be stored by the system.
The Noun Technique
• Steps:
1. Using the use cases, actors, and other
information about the system— including inputs
and outputs—identify all nouns.
• Examples customer, product item, sale, confirmation,
transaction, shipping, bank, change request,
summary report, management, transaction report,
accounting, back order, back-order notification,
return, return confirmation, fulfillment reports,
prospective customer, marketing, customer account,
promotional materials, charge adjustment, sale
details, merchandising, and customer activity reports.
The Noun Technique
2. Using other information from existing systems,
current procedures, and current reports or
forms, add items or categories of information
needed.
• Example: more detailed information, such as price,
size, colour, style, season, inventory quantity, payment
method, and shipping address.
• Some of these items might be additional things, and
some might be specific information (called attributes)
about things you have already identified.
• Refine the list and then record assumptions or issues
to explore.
The Noun Technique
3. As this list of nouns builds, will need to refine it.
• Ask these questions about each noun to help you
decide whether you should include it:
– Is it a unique thing the system needs to know about?
– Is it inside the scope of the system I am working on?
– Does the system need to remember more than one of these
items?
The Noun Technique
• Ask these questions about each noun to decide
whether you should exclude it:
– Is it really a synonym for some other thing I have identified?
– Is it really just an output of the system produced from other
information I have identified?
– Is it really just an input that results in recording some other
information I have identified?
• Ask these questions about each noun to decide
whether you should research it:
– Is it likely to be a specific piece of information (attribute)
about some other thing I have identified?
– Is it something I might need if assumptions change?
The Noun Technique
4. Create a master list of all nouns identified and
then note whether each one should be included,
excluded, or researched further.
5. Review the list with users, stakeholders, and
team members and then refine the list of things
in the problem domain.
Attributes of Things
• The noun technique involves listing all the
nouns that come up in discussions or
documents about the requirements.
• The list can become quite long because many
of these nouns are actually attributes
• Need to decide
– What is domain and attributes
– What to ignore
Attributes of Things
• Decide which to keep and which to ignore
Attributes of Things
• Need to decide what is data entity and what
are the attributes in the data entity.
• For example, a data entity “customer” has the
following attributes:
– name,
– phone number,
– address
– And so on…
Attributes of Things
• The attribute that uniquely identifies the thing
is called an identifier or key.
• Sometimes, the identifier is already
established (a Social Security number, vehicle
ID number, or product ID number).
• Sometimes, the system needs to assign a
specific identifier (an invoice number or
transaction number).
Attributes of Things
• A system may need to remember many similar
attributes.
– For example, a customer has several names: a first name, a
middle name, a last name, and possibly a nickname.
• A compound attribute is an attribute that contains a
collection of related attributes, so an analyst may
choose one compound attribute to represent all
these names, perhaps naming it Customer full name.
Attributes of Things
• A customer might also have several phone
numbers: home phone number, office phone
number, fax phone number, and cell phone
number.
• The analyst might start out by describing the
most important attributes but later add to the
list. Attribute lists can get quite long.
Attributes of Things
• Examples of attributes of a customer and the
values of attributes for specific customers.
Associations among Things
• Many important relationships among things are
important to the system.
• An association is a naturally occurring relationship
between specific things, such as
– an order is placed by a customer
– an employee works in a department
• Information systems need to store information about
things such as employees and departments, but
equally important is storing information about the
specific associations between those things.
Associations among Things
• In database management,
– the term relationship is association in UML.
– Uses entity-relationship diagram (ERD).
• ERD is very similar to UML domain model.
• UML domain model
– form of the class diagram
– very simplified, only important attributes and no method
– Shows : Association, Aggregation, Composition,
Generalization, Multiplicity
Domain Model Class Diagram
• A class is a category or classification used to
describe a collection of objects.
• Each object belongs is an instance of a class.
• Classes that describe things in the problem
domain are called domain classes.
• Domain classes have the following
characteristic among classes:
– Association, Aggregation, Composition,
Generalization, Multiplicity
Domain Model Class Diagram
• On a class diagram,
– rectangles represent classes
Domain Model Class Diagram
• On a class diagram,
– lines connecting the rectangles show the
associations among classes.
Domain Model Class Diagram Notation
• The associations places and consists of are included on the
diagram for clarity.
• Multiplicity
– Each Customer can place many Orders (a minimum of zero and a
maximum of many)
– Each Order is placed by one Customer.
Domain Model Class Diagram Notation
• Summary of multiplicity notation.
Domain Model Class Diagram Notation
• Another example of a domain model class diagram, this one
for the bank with multiple branches
Domain Model Class Diagram Notation
• Example of a domain model class diagram with a
many-to-many association.
• At a university, courses
are offered as course
sections
• A student enrolls in
many course sections.
• Each course section
contains many students.
• Therefore, the
association between
CourseSection and
Student is many-to-
many.
Domain Model Class Diagram Notation
• Analysts often discover that many-to-many associations
involve additional data that are important and must be stored.
• In the previous example, where is the grade that each student
receives for the course stored?
• This is important data, and although the model indicates
which course section a student took, it does not have a place
for the grade.
• Grade isn’t an attribute of CourseSection alone. Nor is it an
attribute of Student alone. Rather, it’s an attribute of the
association between CourseSection and StudentGrade.
Domain Model Class Diagram Notation
• Adding a domain class, called an association class, to
represent the association between Student and
CourseSection provides a place in which to store the missing
attribute for grade.
• A dashed line connects the association class with the asso-
ciation line between the CourseSection and Student classes.
Domain Model Class Diagram Notation
• Reading the association from left to right,
– one course section has many course enrollments—each with its own
grade.
– each course enrollment applies to one specific student.
Domain Model Class Diagram Notation
• Reading from right to left,
– one student has many course enrollments—each with its own grade
– each course enrollment applies to one specific course section.
– A database implemented by using this model will be able to produce
grade lists showing all students and their grades in each course section
as well as grade transcripts showing all grades earned by each student.
Domain Model Class Diagram Notation
• Another example of a domain model class
diagram with a many-to-many association
Domain Model Class Diagram Notation
• A band has one or more band members,
• A band member is in one and only one band. (in this case)
• The many-to-many association is between the classes Band and Concert.
– A band is booked for zero or more concerts, and
– a concert books one or more bands.
• Note that on the minimum multiplicities, a band might not have any
concerts booked at a given time, but a concert is ordinarily created only
when at least one band is booked.
Domain Model Class Diagram Notation
• The analyst discover additional information about
the booking that needs to be captured and
remembered by the system.
An associative class
named Booking that
includes attributes
• dateBooked,
• performanceOrder,
• basePay.
Domain Model Class Diagram Notation
• Reading from Band to Concert,
– one band has many booking—each with its dateBooked
etc.
– each booking applies to one concert.
Domain Model Class Diagram Notation
• Reading from Concert to Band
– one concert has many booking—each with its dateBooked
etc.
– each booking applies to one band
Complex Issues about Classes of Objects
• With class diagrams, there are three types of
relationships among classes of objects:
– association relationships (discussed previously)
– generalization/ specialization relationships,
– whole-part relationships
Generalization/specialization
relationships
• Based on the idea that people classify things
in terms of similarities and differences.
• Generalizations are judgments that group
similar types of things.
Generalization/specialization
relationships
• Used to structure or rank these things from the more general
to the more special.
• For example, there are several types of motor vehicles: cars,
trucks, and tractors.
– All motor vehicles share certain general characteristics, so
a motor vehicle is a more general class.
• For example, special types of cars include sports cars, sedans,
and sport utility vehicles.
– These types of cars are similar in some ways yet different
in other ways. Therefore, a sports car is a special type of
car.
Generalization/specialization
relationships
• Each class of things in the hierarchy might have a more
general class above it, called a superclass.
• At the same time, a class might have a more specialized class
below it, called a subclass.
• UML class diagram notation uses a triangle that points to the
superclass to show a generalization/specialization hierarchy.
Generalization/specialization
relationships
• People structure their understanding by using
generalization/specialization relationships.
• people learn by refining the classifications they make about
some field of knowledge.
• A knowledgeable banker can talk at length about special types
of loans and deposit accounts.
• Therefore, when asking users about their work, the analyst is
trying to understand the knowledge the user has about the
work, which the analyst can represent by constructing
generalization/specialization relationships
Generalization/specialization
relationships
• Inheritance allows subclasses to share characteristics of their
superclass.
– a car is everything any other motor vehicle is but also something
special.
– A sports car is everything any other car is but also something special.
• In this way, the subclass “inherits” the characteristics of the
superclass.
• In the object-oriented approach, inheritance is a key concept
that is possible because of generalization/specialization
hierarchies.
• Also known as inheritance relationships or “IS A” relationship.
• Example “a Sedan IS A special type of Car and a Car IS A
special type of MotorVehicle.”
Generalization/specialization
relationships
A partial domain model for a retail business
Generalization/specialization
relationships
• Attributes are included for each class in the hierarchy.
• Each member of the Sale class has a saleDateTime attribute
and a priorityCode attribute.
• OnlineSale, InStoreSale, and TelephoneSale inherit the
attributes from Sale, plus they have some special attributes of
their own.
– An OnlineSale actually has eight attributes (six from Sale and two
additional).
– An InStoreSale has nine attributes,
– A TelephoneSale has eight attributes.
Generalization/specialization
relationships
• Note that in Figure that the class name Sale is in
italic; that is because it is an abstract class.
• An abstract class is a class that only exists so
subclasses can inherit from it.
• There is never an actual object simply called a Sale.
Each sale must be one of the three subclasses.
Generalization/specialization
relationships
• A concrete class is a class that have actual
objects. Sometimes, a superclass is abstract;
sometimes, it is concrete depending on the
intention of the analyst.
Generalization/specialization
relationships
• The figure shows an extension of
the bank with multiple branches
example to indicate that there are
two types of accounts: a
SavingsAccount and a
CheckingAccount.
• The abstract class Account is in
italic, indicating it is an abstract
class.
Generalization/specialization
relationships
• Each subclass has its own special
attributes that do not apply to the
other subclasses.
• A SavingsAccount has four
attributes, and a CheckingAccount
has five attributes.
• Note that each subclass also
inherits an association with a
Customer, optionally a Branch,
and one or more Transactions.
Whole-Part Relationships
• Used to show an association between one class and
other classes that are parts of that class.
– For example, a computer system is a collection of parts:
processor, main memory, keyboard, disk storage, and
monitor.
– A keyboard; it is part of a computer, but it is also
something separate.
Whole-Part Relationships
• There are two types of whole-part relationships: aggregation
and composition.
• Aggregation refers to a type of whole-part relationship
between the aggregate (whole) and its components (parts),
where the parts can exist separately. (white diamond symbol)
• Composition refers to whole-part relationships that are even
stronger, where the parts, once associated, can no longer exist
separately. (black/filled diamond symbol)
Whole-Part Relationships
• Whole-part relationships—aggregation and
composition—mainly allow the analyst to
express subtle distinctions about associations
among classes.
The State Machine Diagram—
Identifying Object Behaviour
• Sometimes, it is important for a computer system to
maintain information about the status of problem domain
objects.
• For example, a customer might want to know whether a
particular sale has been shipped or a manager might want
to know if a customer sale has been paid for. Thus, the
system needs to be able to track the status of customer
sales.
• When defining requirements, analysts need to identify and
document which domain objects require status checking
and which business rules determine valid status conditions
The State Machine Diagram—
Identifying Object Behaviour
• The status condition for a real-world object is often
referred to as the state of the object.
• A state of an object is a condition that occurs during
its life when it
– satisfies some criterion,
– performs some action, or
– waits for an event.
The State Machine Diagram—
Identifying Object Behaviour
• An object remains in a state until some event
causes it to move, or transition, to another
state.
• A transition is the movement of an object
from one state to another state.
• Transitioning is the mechanism that causes an
object to leave a state and change to a new
state.
The State Machine Diagram—
Identifying Object Behaviour
• State machine diagram:
– Describes the dynamic behaviour, or the possible
behaviour, of the objects in one particular object class.
– Only an object in the problem domain class that have
status conditions that must control the processing for that
object need a state machine diagram.
• For example, a class such as Sale may need a state machine
diagram.
• A class such as SaleTransaction probably does not. A sale
transaction is created when the payment is made and then just
sits there; it doesn’t need to track other conditions.
The State Machine Diagram—
Identifying Object Behaviour
• A state machine diagram is composed of rounded
rectangles representing the states of an object and
arrows representing the transitions. The diagram
shows a simple state machine diagram for a printer.
The State Machine Diagram—
Identifying Object Behaviour
• Pseudostate
– the starting point of a state machine diagram.
– The first shape after the black dot is the first state
of the printer. (the printer begins in the Off state.)
The State Machine Diagram—
Identifying Object Behaviour
• The arrow leaving the Off state is called a transition.
• The firing of the transition causes the object to leave the Off
state and make a transition to the On state.
• After a transition begins, it runs to completion by taking the
object to the new state, called the destination state.
The State Machine Diagram—
Identifying Object Behaviour
• A transition is labeled with a string to describe the
components of the transition.
• The transition label consists of the following syntax with three
components:
• transition-name (parameters, ...) [guard-condition] / action-
expression
The State Machine Diagram—
Identifying Object Behaviour
• The transition-name is onButtonPushed.
• The transition is like a trigger that fires or an event that
occurs.
• The name should reflect the action of a triggering event.
• If there is no triggering event, the trigger is considered to be
constantly firing, and when- ever the guard becomes true, the
transition occurs.
The State Machine Diagram—
Identifying Object Behaviour
• The guard-condition is a qualifier or test on the transition, and it is simply
a true/false condition that must be satisfied before the transition can fire.
• For a transition to fire, first the trigger must occur and then the guard
must evaluate to true.
• The guard-condition is [Safety cover closed]. For the transition to fire, the
guard must be true.
• If the guard-condition is empty, it automatically evaluates to true.
The State Machine Diagram—
Identifying Object Behaviour
• Action-expressions indicate some process that must
occur before the transition is completed and the
object arrives in the destination state. In this case,
the printer will run a start-up procedure before it
goes into the On state.
The State Machine Diagram—
Identifying Object Behaviour
• Concurrent States
– An object can be in two states at the same time.
– For example, when the printer is in the On state, it
can also be either Printing or Idle.
The State Machine Diagram—
Identifying Object Behaviour
• Steps to develop state machine diagrams:
1. Review the class diagram and select the classes
that might require state machine diagrams.
2. For each selected class in the group, make a list
of all the status conditions you can identify.
• At this point, simply brainstorm. Remember that these
states must reflect the states for the real-world objects
that will be represented in software.
3. Begin building state machine diagram fragments
by identifying the transitions that cause an
object to leave the identified state.
The State Machine Diagram—
Identifying Object Behaviour
4. Sequence these state-transition fragments in the
correct order.
5. Review the paths and look for independent,
concurrent paths
6. Look for additional transitions.
7. Expand each transition with the appropriate
message event, guard- condition, and action-
expression.
8. Review and test each state machine diagram.
The State Machine Diagram—
Identifying Object Behaviour
• Example SaleItem
• first step:
– identify the possible status conditions that might
be of interest.
– Some necessary status conditions are
• Open
• Ready to be shipped,
• On back order, and
• Shipped.
The State Machine Diagram—
Identifying Object Behaviour
• Example SaleItem
• second step
– identify exit transitions for each of the status
conditions
– .
The State Machine Diagram—
Identifying Object Behaviour
• Third step:
– Combine the state-transition pairs into fragments
– Build a state machine diagram with the states in the correct sequence
The State Machine Diagram—
Identifying Object Behaviour
• fourth step
– look for concurrent paths.
– In this case, it doesn’t appear that a SaleItem
object can be in any two of the identified states at
the same time.
The State Machine Diagram—
Identifying Object Behaviour
• fifth step:
– look for additional transitions.
– a transition from Open to On back order.
The State Machine Diagram—
Identifying Object Behaviour
• sixth step
– complete all the transitions with correct names,
guard- conditions, and action-expressions.
The State Machine Diagram—
Identifying Object Behaviour
• seventh step
– quality-review step.
– reviewing and testing the state machine diagram
The State Machine Diagram—
Identifying Object Behaviour
• Example InventoryItem
• First and Second steps
– identify the possible status conditions that might be of
interest.
– identify exit transitions for each of the status conditions
The State Machine Diagram—
Identifying Object Behaviour
• Third and fourth steps,
– combine these states and transitions into
fragments and connect them together to give the
first-cut state machine diagram.
The State Machine Diagram—
Identifying Object Behaviour
• Fifth step,
– See if these state-transition fragments are really
concurrent paths.
– In this case, two concurrent paths.
Path 1
Path 2
The State Machine Diagram—
Identifying Object Behaviour
• Sixth step
– complete all the transitions with correct names, guard-
conditions, and action-expressions.
– Path 1 appears to be okay—cycling between Not on order
and On order.
– Path 2, there are transitions that have the same name
(reduceInventory and restock). Need to ensure that the
correct transitions fire and the correct states are used.
The State Machine Diagram—
Identifying Object Behaviour
– reduceInventory transition.
• InventoryItem will receive this message every time an
item is sold.
• However, it only wants to take the transition from one
state to another if it is at
– the reorder point, or
– the last item in stock.
• Add guards to define those conditions.
• Also initiate a reorder process when the InventoryItem
goes to a Low stock or a Zero stock state.
The State Machine Diagram—
Identifying Object Behaviour
– restock transition.
• It is correct.
• Depending on what state the InventoryItem is
in, the correct transition will fire and move to
the Normal stock state.
The State Machine Diagram—
Identifying Object Behaviour
– add a starting initial state and a final state.
– define transitions to createItem for the beginning and deleteItem for
the end.
– DeleteItem is when it is removed completely from the system and the
database.
The State Machine Diagram—
Identifying Object Behaviour
• Benefits of state machine diagram
– helps to capture and clarify business rules.
– As we develop the state machine diagrams, we
must think more deeply about the behaviour of
these objects and what kind of conditions need to
be accounted for in the program code.
– benefits of careful model building help us gain a
true understanding of the system requirements.
Summary
• Domain classes are “Things” end users deal with when
they do their work
– E.g. products, sales, shippers, shipments, and
customers.
• Information systems need to store information about
customers and products, so it is important for the analyst
to identify all the important information about them.
• Techniques to identify domain class or data entity:
– brainstorming technique and
– the noun technique.
Summary
• UML domain model
– takes the form of the class diagram.
– is very simplified with only important
attributes and no method
– shows Association, Aggregation,
Composition, Generalization, Multiplicity
relationship.
Summary
• State machine diagram:
– Describes the dynamic behaviour, or the possible
behaviour, of the objects in one particular object
class.
– Only an object in the problem domain class that
have status conditions that must control the
processing for that object need a state machine
diagram.
– helps to capture and clarify business rules.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 4
System Development Techniques
Diploma in Information Technology
Lesson 8
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
1. Explain system architecture
2. Discuss the design for environment:
• Design for internal deployment (stand-alone software
systems, internal network-based systems, three-layer
client-server architecture)
• Design for external deployment (configuration for
Internet deployment, hosting alternative for internet
deployment, diversity of client devices with internet
deployment)
• Design for remote, distributed environment (demote
deployment via Virtual Private Network(VPN))
Introduction
• Requirements defined during analysis
activities are
– stated in a technologically and architecturally
neutral way.
– stated in a way that enables designers to choose
from a variety of technologies and architectures
• However, system implementers develop and
deploy software using specific technologies
Introduction
• An important part of design is
– choosing appropriate technologies,
– adapting those technologies and software to an
organization’s existing technology architecture,
– modifying existing architecture to support new
technologies and systems.
Anatomy of a Modern System
• Web-based system
– A simplified architectural diagram for the
Amazon.com shopping application.
Anatomy of a Modern System
• Amazon.com shopping application.
– Users interact with the application via a Web
browser running on a personal computing device.
– Those devices normally connect to the Internet
over wireless network connections and from there
to one or more servers that host the Amazon.com
shopping application.
– Other servers host additional software
components to process payment and schedule
shipments.
Server
• Server
– a computer or group of computers that manages
shared resources such as file systems, databases,
and Web sites,
– enables users and other computers to access
those resources over a network.
Server
• Smaller organizations may own a handful of
servers or may “rent” server capacity from
larger organizations.
• Large computing-intensive organizations owns
server “farms” that fill entire buildings and are
interconnected and replicated on a global
scale
Networks
• The true power of modern computing lies in
the ability to interconnect them.
• Computer network:
– a collection of hardware, software, and
transmission media that enables computing
devices to communicate with one another and to
share resources.
• Networks of all sizes interconnect with one
another to form the Internet
Networks
• Internet backbone networks.
– provide the high-capacity, high transmission
speeds, and reliability needed to carry billions of
messages across regions, countries, and
continents.
– Owned and operated by governments or large
telecommunications companies.
Networks
• Local area networks (LANs)
– typically span a single home, small office, or one
floor of a building.
– Servers and personal computing devices connect
wirelessly or via cables to LANs.
– LANs connect to the Internet via larger networks
spanning groups of buildings, cities, or regions.
World Wide Web
• The World Wide Web ( WWW or Web)
– an interconnected set of resources accessed via the
Internet.
– Internet and Web are used interchangeably
– The distinction between them is important for system
designers.
• The Internet is the “highway” over which messages and
information travel from network to network, server to personal
computing device, and service provider to end user.
• The Web is the set of resources and services that can be accessed
via that highway.
World Wide Web
• Web resources
– static documents: web pages, images, videos,
– e-mail and other messages,
– software-based services such as shopping sites
and online games.
World Wide Web
• Uniform Resource Locator (URL)
– To identify Web resources
– composed of three parts:
World Wide Web
• Hyperlink.
– Embed the URL of one Web resource within
another Web resource.
– Documents, embedded hyperlinks, and the
resources pointed to by those hyperlinks form a
connection network that resembles a large spider
web when diagrammed
• Thus the name World Wide Web.
Software
• Two types.
– Application software
– System software
• Application software
– software that performs user or business-specific
tasks
– App : installed once on a computer or cell phone’s
storage device.
– Web-based: applications that run within a Web
browser.
Software
• System software
– software that works behind the scenes to support
application software and to control or interact
with hardware or software resources.
• operating systems (OSs)
– controls what a device can and can’t do, thus enabling or
limiting the application software that can be used on the
device.
• database management systems,
• Web browsers
• Web server software
Software
Web-Based Applications
• Characteristics of Web-based applications:
– Use of a Web browser as the primary user
interface on personal computing devices
– User access to the Web application via a URL
– Server-side software components that execute on
or are called from a Web server
– Use of Web standards for communication
between Web browser and server
Web-Based Applications
• Web applications are common because of
ease of access and use of widely adopted Web
standards.
• However, those benefits come at a cost.
– Web applications are a well-defined target for
security breaches because URLs and Web
standards are open and widely known.
– Application performance can suffer when
networks are congested
Embedded Software
• The OS has embedded software that provides
functions for
– graphical display, touch screen and gesture-based
input, voice recognition, speech generation, music
and video playback, and access to the Internet
and Web resources.
• Able to reuse the all those embedded
software across different application.
Embedded Software
• Reuse benefits,
– a similar look and feel across applications
– application development toolkits for software
developers that automate many programming
tasks
– provide a direct interface to software already
embedded in the device.
Protocols
• Protocol
– is a set of languages, rules, and procedures that
ensure accurate and efficient data exchange and
coordination among hardware and software
components.
– Hardware, software, and network components
operate on common protocols for communication.
Protocols
• .
Network Protocols
• Network protocols
– enable accurate message transmission among the
various computers and software components.
– enables messages to find their way from sender to
recipient, enable multiple devices to efficiently
share wireless and wired connections, and handle
tasks such as identifying and retransmitting lost
messages.
– implemented within all computers and network
hardware devices.
Network Protocols
• Firewalls
– examine incoming and outgoing packets and block
those arriving from or sent to “dangerous” URLs
or network address.
– Thus, an information system designer must ensure
that network messages among software
components won’t be blocked by a firewall at
either end.
Network Protocols
• Virtual private network (VPN)
– isolate sensitive communications between servers
or between an organization’s own employees and
servers.
– incorporates technologies Secure Sockets Layers,
Transport Layer Security, and secure IP,
– reliably identify senders and recipients, and
encrypt network messages sent among them.
Web Protocols
• Hypertext Transfer Protocol (HTTP).
– Defines the format and content of requests for Web
documents and resources,
– includes some simple commands for other types of
requests, such as uploading a file or page.
– Web browsers normally request that a Web page be
transmitted for display via the HTTP GET command.
– Data entered by a user in an HTML form is normally
transmitted back to a Web server using the HTTP POST
command
Web Protocols
• Hypertext Transfer Protocol Secure (HTTPS).
– Extension of HTTP that employs secure network
protocols to reliably identify senders and
recipients and encrypt network messages sent
among them
Architectural Concepts
• Technology architecture.
– The set of computing hardware, network hardware and
topology, and system software employed by an
organization
– defines the infrastructure that supports application
software and the services it provides.
• Application architecture.
– The set of information systems (the software applications)
the organization needs to support its strategic plan.
– deployed on a technology architecture by distributing
application components to specific hardware devices and
connecting them via networks and protocols.
Architectural Concepts
• Technology and application architecture are interdependent.
– Poor technology architecture provides a weak foundation
for application software and can comprise its performance,
reliability, and other characteristics.
– Good technology architecture enhances those
characteristics and provides other benefits, such as
minimal operating cost and flexible updating.
– High-quality technology architecture can’t make up for
poor application architecture.
– Application software must be designed to ensure ease of
construction, deployment, operation, and future updates.
Software as a Service
• Software as a service (SaaS)
– Software distribution model in which a third-party
provider hosts applications and makes them
available to customers over the Internet.
– Little or no application software is installed on the
user’s device.
– User data is stored on servers, though copies may
be stored on the user’s device for improved
performance.
Web Services
• Web service
– a software service accessed over the Internet
using Web protocols.
– commonly refers to smaller and more focused
applications, such as transmitting shipping
information from seller to shipper, or single
functions, such as looking up the zip code that
matches a shipping address.
Web Services
• Web Services meets the following criteria:
– Is “called” from one application via a URL or other
Web protocol
– Accepts input data embedded within the URL or
via another protocol
– Executes on the Web service owner’s servers
– Returns processing results encoded within a Web
page or document
Web Services
• Web services enable software functions
developed by organizations to be embedded
within the information system of another
organization.
• For example:
– Amazon web application passes shipment details
to shipper (e.g. Fedex or UPS) web services.
Web Services
• Knowledge of Web services are important for system
design
– Scan the range of available Web services and decide which
to incorporate into their software.
– expand the functions of their own software with minimal
related development cost.
– Decide which (if any) functions of their own software
should be implemented as Web services and made
available to other systems.
• increase the potential base of software users, but also commit to
making those services available in a reliable and secure fashion
over a long time period.
Distributed Architectures
• Client/Server Architecture
– divides software into two classes: client and
server.
– A server manages system resources and provides
access to these resources through a well-defined
communication interface.
– A client uses the communication interface to
request resources, and the server responds to
these requests.
Distributed Architectures
• Three-Layer Architecture
– a variant of client/server architecture that is used for all
types of systems, from internally deployed desktop
applications to globally distributed Web-based
applications.
– divides the application software into three layers that
interact, as shown
Distributed Architectures
• Three-Layer Architecture
– The user interface or view layer, which accepts user input
and formats and displays processing results
– The business logic layer or domain layer, which
implements the rules and procedures of business
processing
– The data layer, which manages stored data, usually in one
or more databases
Distributed Architectures
Interoperability
• Interoperability
– is the ability of a component or system to interact
with other components or systems.
– Allows hardware and software components that
make up a modern information system must work
together
Interoperability
• To ensure interoperability, system designers must:
– Understand and describe the current environment in
which the system will operate.
• That environment includes existing hardware and software
components, networks, and the protocols and APIs already in use.
– Look for existing software components and services that
can provide needed functions for the new system. Those
functions must be interoperable with the existing
environment and with components that will be built.
Architectural Diagrams
• Location diagrams
– Used to show the geographic placement of
various system components, including hardware,
buildings, and users.
Architectural Diagrams
• Network diagram
– shows how locations and hardware components
are interconnected with network devices and
wiring.
Architectural Diagrams
• Deployment Diagrams
– describes how software components are
distributed across hardware and system software
components.
Architectural Diagrams
• On the left, an application server hosts Microsoft
Internet Information Server, which in turn hosts
multiple CSMS subsystems. The subsystems and their
dependencies are represented as embedded package
diagrams.
Architectural Diagrams
• On the right, a database server hosts Microsoft SQL
Server 2013 as the database management system
(DBMS). In turn, the DBMS hosts three database
schemas that provide permanent storage of
customer, order, and product data.
Architectural Diagrams
• Software components in the application
server communicate with the DBMS using SQL
as the primary protocol and database access
language.
Describing the Environment
• Describing the environment is the first design
activity.
• Two key elements:
– External systems
– Technology architecture
• Covered in previous lecture
Designing Application Components
• Application component
– a well-defined unit of software that performs one
or more specific tasks.
– self-contained unit of functionality.
– modular, deployable, and replaceable part of a
software system that encapsulates its behaviour
and data and exposes these through a set of
interfaces.
Designing Application Components
• The designer thinks of the entire system as a single
component performing all of the functions described
during analysis activities.
• The designer then breaks this large component into
smaller components in a generic process called
factoring.
• The designer considers each function separately and
looks for similarities as a basis for grouping software
that implements the functions into larger application
components.
Designing Application Components
• Designer looks for similarities among system functions to
guide factoring or grouping.
• Focus on specific analysis activity descriptions like events and
use cases.
– Actors. Each use case identifies one or more specific actors. Software
for use cases that interact with the same actors is a candidate for
grouping into a single application component.
– Shared data. Use cases that interact with the same domain class(es)
are candidates for grouping into a single application component.
– Events. Use cases that are triggered by the same external, temporal,
or state event are candidates for grouping into a single application
component
Application Component
Boundaries
Group similar uses cases together into a group to identify the
application components boundaries
In the example we have the following group:
• Group A – Phone sales
• Group B – Store sales
• Group C – online sales – shipment and tracking
• Group D – online sales – shopping cart
• Group E – Customer account
Application Component
Boundaries
• Group A – Phone sales
• Group B – Store sales
• Group C – online sales – shipment and tracking
Application Component
Boundaries
• Group D – online sales – shopping cart
Application Component
Boundaries
• Group E – Customer account
Deployment diagram
• Consider that five different actors will interact with
the use cases
– Phone sales representative. Interacts with the customer by phone
while using a desktop computer to perform sale and return functions
– Store sales representative. Interacts with the customer in person
while using a point-of-sale terminal or tablet computer
– Customer. Performs functions using a smartphone, tablet, laptop,
desktop computer, or other device (e.g., an Internet-capable
television)
– Shipping. Performs return functions using a tablet or desktop
computer
– Management. Performs order and shipment functions using a tablet,
laptop, or desktop computer
Deployment diagram
• Design the View layer Application Component
Deployment diagram
• Deployment diagram describing the three-
layer architecture for the use cases
Deployment diagram
• The deployment diagram business layer can
be further divided into many packages
– Group A and B - Phone sales and Store sales
– Group C – online sales – shipment and tracking
– Group D – online sales – shopping cart
– Group E – Customer account
• Feedback
• Friends
• Mountain bucks
• Note group A and B is merge into one package because it is very similar.
• Group E can be split into three sub packages
Summary
• Requirements defined during analysis activities are
stated in a technologically and architecturally neutral
way.
• The system designer needs to choose appropriate
technologies, adapt those technologies and software
to an organization’s existing technology architecture
and modify existing architecture to support new
technologies and systems.
Summary
• Architectural Diagrams consists of Location
diagrams, Network diagram and Deployment
Diagrams
• Deployment Diagrams describes how software
components are distributed across hardware
and system software components.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 7
System Development Techniques
Diploma in Information Technology
Lesson 10
Learning outcomes
After studying this chapter and the recommended
reading, you should be able to:
• Explain user-interface design concepts
• Describe the transition from analysis to user-
interface design
• Discuss user and system interfaces
• Explain user-interface design
Introduction
• User interface design between a system and its users
is an important systems design task.
• Poorly designed interfaces with people can result in a
system that operates less than optimally or doesn’t
fulfil its purpose.
• Designing user interface are both analysis activities
and design activities.
Introduction
• User interface during Analysis activity
– discussion of inputs and outputs with stakeholders
to identify users and actors and the information
they need to carry out their business processes
– screen layout and storyboard is a discovered with
deep understanding of the user processes and
needs.
Introduction
• User-interface design during Design activity
– utilizes other analysis models as input, e.g. system
sequence diagram.
– produces models in the form of sample layouts
that are used by programmers to implement the
final system.
Introduction
User-interface design need to consider
– the entire user experience
– what devices are being used and what the users
are doing on those devices.
– the type of device:
• desktop, laptop, tablet, or smartphone,
– Type of OS
• iOS, Android or Windows devices.
Understanding the User Experience
and the User Interface
• User Experience (UX)
– a broad concept that applies to all aspects of a
person’s interaction with a product or service.
– includes user
• actions, responses, perceptions, feelings
• anticipation when using the software application.
Understanding the User Experience
and the User Interface
• User Interface (UI)
– the set of inputs and outputs that directly involve
an application user.
– the part of the system that the user sees and
interacts with.
– the only part of the system that the users see, to
them the user interface is the system.
Understanding the User Experience
and the User Interface
• User Interface (UI)
– varies widely depending on such factors as interface
purpose, user characteristics, and characteristics of a
specific interface device.
– For example,
• internal users
– design for operational efficiency
– can be trained to use a specific interface optimized for a specific
hardware device
• general customer-accessible system
– Assumes a cell phone as the input/output device.
– design for general ease of use
Understanding the User Experience
and the User Interface
• User Interface (UI)
– must be integrated into all elements of the system
development.
– should not be developed and added to the system
near the end of the development process.
Understanding the User Experience
and the User Interface
• User-centered design
– Three important principles:
• Focus early and throughout the project on the users
and their work.
• Evaluate all designs to ensure usability.
• Use iterative development.
Understanding the User Experience
and the User Interface
• Usability
– how easy a system is to learn and use.
– ensuring usability isn’t easy; there are many different
types of users with different preferences and skills.
– If the system has a variety of end users, how can the
designer be sure that the interface will work well for all of
them?
• if it is too flexible, some end users might feel lost.
• if the interface is too rigid, some users will be frustrated.
Understanding the User Experience
and the User Interface
• Usability
– ease of learning and ease of use are in conflict.
• Easy to learn
– menu-based applications with multiple forms, many dialog boxes,
and extensive prompts and instructions are easy to learn and self-
explanatory.
– appropriate for systems that end users use infrequently.
• Easy to use
– internal users use the system all day,
– important to make the interface fast and flexible, with shortcuts, hot
keys, voice commands, and information-intensive screens.
– might be harder to learn, but it will be easier to use after it is
learned.
Understanding the User Experience
and the User Interface
• Metaphors
– items that appear on the screens are virtual
entities.
– Items exist only as images and sounds.
– Therefore, helpful for Human-Computer Interface
(HCI) developers to use metaphors based on real-
world physical entities and actions to design a
user interface with a positive user experience.
Understanding the User Experience
and the User Interface
• Metaphors
– make computers easier to use and learn,
– analogies between features of the user interface
and aspects of physical reality that users are
familiar with.
– widely applied to user-interface design (see next
table)
Understanding the User Experience
and the User Interface
• Metaphors
Fundamental Principles of User-
Interface Design
• Human-interface objects (HIOs)
– objects that appear on a screen the user can
manipulate.
– e.g. documents, buttons, menus, folders, and
icons.
Fundamental Principles of User-
Interface Design
• Human-interface objects (HIOs)
– Use HIOs That Reflect Their Purpose or Behaviour
(Affordance)
• Mostly used in buttons or other small icons
• Affordance: the appearance of a specific
control suggests its function
– For example, a control that looks like a steering
wheel suggests that it is used for turning.
– can also be achieved by a user-interface control that
the user is familiar with in another context.
» For example, the media player control icons shown in
most music player.
Fundamental Principles of User-
Interface Design
• Human-interface objects (HIOs)
– HIOs Should Provide Visual Feedback When
Activated
• visual or audio response by the system in response to
some user action
• immediate feedback on mouseover or mouse click.
• Feedback provides the user with a sense of
confirmation and the feeling that a system is responsive
and functioning correctly.
• Lack of feedback leaves the user wondering whether a
command or input was recognized or whether the
system is malfunctioning.
Fundamental Principles of User-
Interface Design
• Human-interface objects (HIOs)
– HIOs Should Provide Visual Feedback When
Activated
• visual or audio response by the system in response to
some user action
• immediate feedback on mouseover or mouse click.
• Feedback provides the user with a sense of
confirmation and the feeling that a system is responsive
and functioning correctly.
• Lack of feedback leaves the user wondering whether a
command or input was recognized or whether the
system is malfunctioning.
Fundamental Principles of User-
Interface Design
• Consistency
– effectiveness of the user experience is highly
dependent on consistency.
– different levels or areas where consistency should
be maintained.
• Consistency Within and Across Platforms
• Consistency Within a Suite of Applications
• Consistency Within an Application
Fundamental Principles of User-
Interface Design
• Consistency Versus Continuity
– changes occurring in new releases of an application.
– maintains a certain level of consistency over time across
multiple releases.
– problem designers have is understanding how to add new
functionality while maintaining continuity across new
releases.
• may not be possible to maintain complete consistency while
adding new functions,
• but continuity should be maintained so that users can easily
transition into the new release.
Fundamental Principles of User-
Interface Design
• Discoverability
– feature of the user interface that provides clues to
help the users uncover hidden features.
– Two ways:
• Use Active Discovery to Help Find Hidden Features
• Use Visual Diagrams to Help Users Discover Functions
or Tools
Fundamental Principles of User-
Interface Design
• Discoverability
– Use Active Discovery to Help Find Hidden Features
– Active discovery
• is a user-interface feature that leads users into
discovering hidden features.
– have a pop-up window appear at application initiation that
provides hints and additional features.
– have a small text box appear as the user hovers over different
locations of the screen.
Fundamental Principles of User-
Interface Design
• Discoverability
– Use Visual Diagrams to Help Users Discover
Functions or Tools
– a simple diagram that is very expressive of how to
perform a desired action.
Fundamental Principles of User-
Interface Design
• Closure
– based on the dialogue metaphor
– a use case requires several steps to complete.
• the user interface should have a clearly defined
beginning and ending.
– Provide feedback on the HIOs (e.g. button, icons)
Fundamental Principles of User-
Interface Design
• Closure
– For a single step
• have a message pop up saying that the work was saved
or the action was completed.
– When a use case requires several steps,
• important that the user know that all the steps are
completed.
• have a Continue button and a Finish button that
indicate the end of the process.
• can include progress bar is also included and a final
message to indicate that the dialogue has successfully
finished.
Fundamental Principles of User-
Interface Design
• Readability and Navigation
– Text Should Be Readable (Font Type, Size, and
Colour)
– Navigation Should Be Clear
– Always Allow a Way Out
• When the user is entering data, should be able to
immediately escape from that form or page without
changing the system.
• input forms have a Cancel button to immediately back
out of the specific form.
Fundamental Principles of User-
Interface Design
• Readability and Navigation
– can be difficult to support in multiple devices.
– large desktop screens usually are quite readable,
– readability with small mobile devices is often a serious
problem.
– large desktop screens also have a lot of space for clues
about navigating through various screens of an application.
– small screens on mobile devices often require that the
navigation tools be hidden or partially hidden.
Fundamental Principles of User-
Interface Design
• Usability and Efficiency
– the entire user experience must be considered to
make an application effective and usable.
• Provide Shortcut Keys to Support Experienced Users
• Design Error Messages That Provide Solution Options
• Design for Simplicity
Transitioning from Analysis to User-
Interface Design
• User-interface design built from
– use case descriptions
• Grouping of related use cases to identify main menu
items.
• starting point for a dialogue or form
– activity diagrams
– system sequence diagrams.
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– Menus
• provide the mechanisms first to organize use
cases and to invoke a particular use case or
user dialogue.
• needed to present the user with a number of
choices per screen,
• to group related functions together so users
can more easily locate them.
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– How many main menu items?
• by the number of uses cases or menu choices,
and by the limits of human cognition.
• For a typical business system, dividing the total
number of interactive use cases by five
provides an initial estimate of the number of
menus needed
• allows for additional menu items, such as
setting options or preferences.
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– How to group use cases into one menu item
• Use cases with common actors and Event
decomposition
• Use cases that implement CRUD actions for a
specific domain class
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– How to group use cases into one menu item
• For example, an
initial grouping of
these cases by
actor and
subsystem is a
good starting point
for menu design.
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– How to group use cases into one menu item
• use cases grouped
into first-cut menus
by similar function
and user
Transitioning from Analysis to User-
Interface Design
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– Each menu collects uses cases from one
subsystem for a customer or internal sales
representative.
– The number of menu choices ranges from four to
seven,
• won’t overload any one menu
• may enable multiple menu levels to be displayed at one
time.
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– A dialogue design is created for each menu
option.
– You should note that designers often discover
missing or incomplete use cases during user-
interface design, which results in a brief return to
analysis activities to complete the documentation.
– (One of the reason we need to start GUI design
early)
Transitioning from Analysis to User-
Interface Design
• Use Cases and the Menu Hierarchy
– Menus
• include options that are not activities or use
cases from the event list.
• Many of these options are related to the
system controls, such as account maintenance
or database backup and recovery
• Other added items include help links as well as
links to other menus or subsystems.
Transitioning from Analysis to User-
Interface Design
• Analysis Models and Input Forms
– A system sequence diagram
• identified individual messages coming from the
external actor into the system.
• The messages represent forms or input screens
to pass information into and out of the system.
• a good starting point to identify the various
screens and forms that may be needed for the
user interface for a particular use case.
Transitioning from Analysis to User-
Interface Design
• Analysis Models and Input Forms
Transitioning from Analysis to User-
Interface Design
• Analysis Models and Input Forms
– This figure shows six separate data flows across
the system boundary.
– Part of the user-interface design process is to
decide how to design the screens for these six
data flows.
– One pair (in and out) data flow can be on the
same screen
Transitioning from Analysis to User-
Interface Design
• Dialogues and Storyboards
– After identifying all required dialogues, the
designer list the key steps how the dialogues
works together.
– Include a description of what the user and
computer do at each step.
– The format for writing these steps can mimic the
activity diagram.
User-Interface Design
• Need to consider design for different type of
devices:
– Desktop and Laptop User Interfaces
– Web-Based Applications
– Tablets
Summary
• User interface design between a system and its users
is an important systems design task.
• Designing user interface are both analysis activities
and design activities.
• Three important principles for User-centered design
• Focus early and throughout the project on the
users and their work.
• Evaluate all designs to ensure usability.
• Use iterative development.
Summary
• The fundamental Principles of User-Interface Design
includes:
– Affordance
– Consistency
– Consistency Versus Continuity
– Discoverability
– Closure
– Readability and Navigation
– Usability and Efficiency
Summary
• User-interface design built from
– use case descriptions
– activity diagrams
– system sequence diagrams.
• Storyboards are constructed using the
designed dialogues
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 8
CATEGORIES
Economics
Nursing
Applied Sciences
Psychology
Science
Management
Computer Science
Human Resource Management
Accounting
Information Systems
English
Anatomy
Operations Management
Sociology
Literature
Education
Business & Finance
Marketing
Engineering
Statistics
Biology
Political Science
Reading
History
Financial markets
Philosophy
Mathematics
Law
Criminal
Architecture and Design
Government
Social Science
World history
Chemistry
Humanities
Business Finance
Writing
Programming
Telecommunications Engineering
Geography
Physics
Spanish
ach
e. Embedded Entrepreneurship
f. Three Social Entrepreneurship Models
g. Social-Founder Identity
h. Micros-enterprise Development
Outcomes
Subset 2. Indigenous Entrepreneurship Approaches (Outside of Canada)
a. Indigenous Australian Entrepreneurs Exami
Calculus
(people influence of
others) processes that you perceived occurs in this specific Institution Select one of the forms of stratification highlighted (focus on inter the intersectionalities
of these three) to reflect and analyze the potential ways these (
American history
Pharmacology
Ancient history
. Also
Numerical analysis
Environmental science
Electrical Engineering
Precalculus
Physiology
Civil Engineering
Electronic Engineering
ness Horizons
Algebra
Geology
Physical chemistry
nt
When considering both O
lassrooms
Civil
Probability
ions
Identify a specific consumer product that you or your family have used for quite some time. This might be a branded smartphone (if you have used several versions over the years)
or the court to consider in its deliberations. Locard’s exchange principle argues that during the commission of a crime
Chemical Engineering
Ecology
aragraphs (meaning 25 sentences or more). Your assignment may be more than 5 paragraphs but not less.
INSTRUCTIONS:
To access the FNU Online Library for journals and articles you can go the FNU library link here:
https://www.fnu.edu/library/
In order to
n that draws upon the theoretical reading to explain and contextualize the design choices. Be sure to directly quote or paraphrase the reading
ce to the vaccine. Your campaign must educate and inform the audience on the benefits but also create for safe and open dialogue. A key metric of your campaign will be the direct increase in numbers.
Key outcomes: The approach that you take must be clear
Mechanical Engineering
Organic chemistry
Geometry
nment
Topic
You will need to pick one topic for your project (5 pts)
Literature search
You will need to perform a literature search for your topic
Geophysics
you been involved with a company doing a redesign of business processes
Communication on Customer Relations. Discuss how two-way communication on social media channels impacts businesses both positively and negatively. Provide any personal examples from your experience
od pressure and hypertension via a community-wide intervention that targets the problem across the lifespan (i.e. includes all ages).
Develop a community-wide intervention to reduce elevated blood pressure and hypertension in the State of Alabama that in
in body of the report
Conclusions
References (8 References Minimum)
*** Words count = 2000 words.
*** In-Text Citations and References using Harvard style.
*** In Task section I’ve chose (Economic issues in overseas contracting)"
Electromagnetism
w or quality improvement; it was just all part of good nursing care. The goal for quality improvement is to monitor patient outcomes using statistics for comparison to standards of care for different diseases
e a 1 to 2 slide Microsoft PowerPoint presentation on the different models of case management. Include speaker notes... .....Describe three different models of case management.
visual representations of information. They can include numbers
SSAY
ame workbook for all 3 milestones. You do not need to download a new copy for Milestones 2 or 3. When you submit Milestone 3
pages):
Provide a description of an existing intervention in Canada
making the appropriate buying decisions in an ethical and professional manner.
Topic: Purchasing and Technology
You read about blockchain ledger technology. Now do some additional research out on the Internet and share your URL with the rest of the class
be aware of which features their competitors are opting to include so the product development teams can design similar or enhanced features to attract more of the market. The more unique
low (The Top Health Industry Trends to Watch in 2015) to assist you with this discussion.
https://youtu.be/fRym_jyuBc0
Next year the $2.8 trillion U.S. healthcare industry will finally begin to look and feel more like the rest of the business wo
evidence-based primary care curriculum. Throughout your nurse practitioner program
Vignette
Understanding Gender Fluidity
Providing Inclusive Quality Care
Affirming Clinical Encounters
Conclusion
References
Nurse Practitioner Knowledge
Mechanics
and word limit is unit as a guide only.
The assessment may be re-attempted on two further occasions (maximum three attempts in total). All assessments must be resubmitted 3 days within receiving your unsatisfactory grade. You must clearly indicate “Re-su
Trigonometry
Article writing
Other
5. June 29
After the components sending to the manufacturing house
1. In 1972 the Furman v. Georgia case resulted in a decision that would put action into motion. Furman was originally sentenced to death because of a murder he committed in Georgia but the court debated whether or not this was a violation of his 8th amend
One of the first conflicts that would need to be investigated would be whether the human service professional followed the responsibility to client ethical standard. While developing a relationship with client it is important to clarify that if danger or
Ethical behavior is a critical topic in the workplace because the impact of it can make or break a business
No matter which type of health care organization
With a direct sale
During the pandemic
Computers are being used to monitor the spread of outbreaks in different areas of the world and with this record
3. Furman v. Georgia is a U.S Supreme Court case that resolves around the Eighth Amendments ban on cruel and unsual punishment in death penalty cases. The Furman v. Georgia case was based on Furman being convicted of murder in Georgia. Furman was caught i
One major ethical conflict that may arise in my investigation is the Responsibility to Client in both Standard 3 and Standard 4 of the Ethical Standards for Human Service Professionals (2015). Making sure we do not disclose information without consent ev
4. Identify two examples of real world problems that you have observed in your personal
Summary & Evaluation: Reference & 188. Academic Search Ultimate
Ethics
We can mention at least one example of how the violation of ethical standards can be prevented. Many organizations promote ethical self-regulation by creating moral codes to help direct their business activities
*DDB is used for the first three years
For example
The inbound logistics for William Instrument refer to purchase components from various electronic firms. During the purchase process William need to consider the quality and price of the components. In this case
4. A U.S. Supreme Court case known as Furman v. Georgia (1972) is a landmark case that involved Eighth Amendment’s ban of unusual and cruel punishment in death penalty cases (Furman v. Georgia (1972)
With covid coming into place
In my opinion
with
Not necessarily all home buyers are the same! When you choose to work with we buy ugly houses Baltimore & nationwide USA
The ability to view ourselves from an unbiased perspective allows us to critically assess our personal strengths and weaknesses. This is an important step in the process of finding the right resources for our personal learning style. Ego and pride can be
· By Day 1 of this week
While you must form your answers to the questions below from our assigned reading material
CliftonLarsonAllen LLP (2013)
5 The family dynamic is awkward at first since the most outgoing and straight forward person in the family in Linda
Urien
The most important benefit of my statistical analysis would be the accuracy with which I interpret the data. The greatest obstacle
From a similar but larger point of view
4 In order to get the entire family to come back for another session I would suggest coming in on a day the restaurant is not open
When seeking to identify a patient’s health condition
After viewing the you tube videos on prayer
Your paper must be at least two pages in length (not counting the title and reference pages)
The word assimilate is negative to me. I believe everyone should learn about a country that they are going to live in. It doesnt mean that they have to believe that everything in America is better than where they came from. It means that they care enough
Data collection
Single Subject Chris is a social worker in a geriatric case management program located in a midsize Northeastern town. She has an MSW and is part of a team of case managers that likes to continuously improve on its practice. The team is currently using an
I would start off with Linda on repeating her options for the child and going over what she is feeling with each option. I would want to find out what she is afraid of. I would avoid asking her any “why” questions because I want her to be in the here an
Summarize the advantages and disadvantages of using an Internet site as means of collecting data for psychological research (Comp 2.1) 25.0\% Summarization of the advantages and disadvantages of using an Internet site as means of collecting data for psych
Identify the type of research used in a chosen study
Compose a 1
Optics
effect relationship becomes more difficult—as the researcher cannot enact total control of another person even in an experimental environment. Social workers serve clients in highly complex real-world environments. Clients often implement recommended inte
I think knowing more about you will allow you to be able to choose the right resources
Be 4 pages in length
soft MB-920 dumps review and documentation and high-quality listing pdf MB-920 braindumps also recommended and approved by Microsoft experts. The practical test
g
One thing you will need to do in college is learn how to find and use references. References support your ideas. College-level work must be supported by research. You are expected to do that for this paper. You will research
Elaborate on any potential confounds or ethical concerns while participating in the psychological study 20.0\% Elaboration on any potential confounds or ethical concerns while participating in the psychological study is missing. Elaboration on any potenti
3 The first thing I would do in the family’s first session is develop a genogram of the family to get an idea of all the individuals who play a major role in Linda’s life. After establishing where each member is in relation to the family
A Health in All Policies approach
Note: The requirements outlined below correspond to the grading criteria in the scoring guide. At a minimum
Chen
Read Connecting Communities and Complexity: A Case Study in Creating the Conditions for Transformational Change
Read Reflections on Cultural Humility
Read A Basic Guide to ABCD Community Organizing
Use the bolded black section and sub-section titles below to organize your paper. For each section
Losinski forwarded the article on a priority basis to Mary Scott
Losinksi wanted details on use of the ED at CGH. He asked the administrative resident