DIT SDT Study Guide

SINGAPORE INSTITUTE OF
MANAGEMENT
Diploma in Information Technology
System Development Techniques
Version 1.0
System Copyright by SIM GE, 2021 1

Development Version 1.0
Techniques Restricted
Study Guide
Study Guide Developer : Aaron Yeo Sze Wee
Production : SIM Global Education
Study Guide © SIM Global Education 2021

All rights reserved.
No part of this material may be reproduced in any form or by any means.
without permission in writing from SIM Global Education
First Version @ September 2021

Table of Contents
CHAPTER 1: INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN ................................... 12
1.1 System analysis................................................................................................................... 12
1.2 Systems design ................................................................................................................... 12
1.3 Systems analysis and design ............................................................................................... 13
1.4 The System Development Life Cycle (SDLC) ......................................................................... 13
1.5 Agile Development ............................................................................................................. 14
1.6 Benefits .............................................................................................................................. 15
CHAPTER 1 EXERCISES .............................................................................................................. 16
CHAPTER 2: SYSTEMS REQUIREMENTS ............................................................................ 19
2.1 System analysis................................................................................................................... 19
2.1.1 Gather detailed information............................................................................................... 20
2.1.2 Define Requirements .......................................................................................................... 20
2.1.3 Prioritize Requirements ...................................................................................................... 20
2.1.4 Develop User-Interface Dialogs .......................................................................................... 20
2.1.5 Evaluate Requirements with Users..................................................................................... 21
2.2 System Requirements ......................................................................................................... 21
2.2.1 Functional requirements .................................................................................................... 21
2.2.2 Non-functional requirements ............................................................................................. 21
2.3 Stakeholders ....................................................................................................................... 22
2.4 Information-Gathering Techniques ..................................................................................... 22
2.4.1 Interviewing users and other stakeholders ........................................................................ 22
2.4.2 Distributing and collecting questionnaires ......................................................................... 22
2.4.3 Reviewing inputs, outputs, and documentation ................................................................ 23
2.4.4. Observing and documenting business procedures............................................................ 23
2.4.5 Researching vendor solutions............................................................................................. 23
2.4.6 Collecting active user comments and suggestions ............................................................. 23
2.5 Documenting Workflows with Activity Diagrams ................................................................ 24
CHAPTER 3: USE CASES .................................................................................................... 30
3.1 User Stories and Use Cases ................................................................................................. 30
3.2 User Stories ........................................................................................................................ 30
3.3 Use Case ............................................................................................................................. 30
3.3.1 User Goal Technique .......................................................................................................... 31
3.3.2 Event Decomposition ......................................................................................................... 31
3.4 Perfect technology assumption ........................................................................................... 34
3.5 Event Decomposition to identify use cases ......................................................................... 34
3.6 Use case diagram ................................................................................................................ 35
3.7 Use case diagram examples «includes» Relationships ......................................................... 39
3.8 Developing a Use Case Diagram .......................................................................................... 40
CHAPTER 4: Introduction to CASE tool – StarUML™ ......................................................... 43
4.1 StarUML™ ........................................................................................................................... 43
4.2 User case diagram............................................................................................................... 43
4.3 Activity diagram.................................................................................................................. 44
4.4 Class diagram...................................................................................................................... 45
4.5 State machine diagram ....................................................................................................... 46
4.6 Sequence diagram .............................................................................................................. 46
CHAPTER 5: Domain Modelling ........................................................................................ 50
5.1 Domain classes (data entities) ............................................................................................ 50
5.1.1 The Brainstorming Technique............................................................................................. 50
5.1.2 The Noun Technique .......................................................................................................... 51
5.2 Attributes of Things ............................................................................................................ 52
5.3 Associations among Things ................................................................................................. 53
5.4 Complex Issues about Classes of Objects............................................................................. 57
5.4.1 Generalization/specialization relationships ....................................................................... 57
5.4.2 Whole-Part Relationships ................................................................................................... 60
5.5 The State Machine Diagram - Identifying Object Behaviour ................................................ 61
5.5.1 Example to develop state machine diagrams: SaleItem ..................................................... 63
5.5.2 Example to develop state machine diagrams: InventoryItem ........................................... 65
5.6 Benefits of state machine diagram ...................................................................................... 67
CHAPTER 6: Extending Requirements Models .................................................................. 70
6.1 Use Case Descriptions ......................................................................................................... 70
6.2 Activity Diagrams for Use Cases .......................................................................................... 73
6.3 The System Sequence Diagram ........................................................................................... 76
6.4 Developing a System Sequence Diagram (SSD) .................................................................... 79
6.5 Use Cases and CRUD ........................................................................................................... 81
6.6 Integrating Requirements Models ....................................................................................... 82
CHAPTER 7: Essentials of Systems Design 1 ...................................................................... 86
7.1 Systems Design ................................................................................................................... 86
7.2 Design Activities ................................................................................................................. 88
7.2.1 Describe the Environment .................................................................................................. 89
7.2.2 Design the Application Components .................................................................................. 89
7.2.3 Design the User Interface ................................................................................................... 91
7.2.4 Design the Database ........................................................................................................... 91
7.2.5 Design the Software Classes and Methods......................................................................... 92
7.3 System Controls and Security .............................................................................................. 93
CHAPTER 8: Essentials of Systems Design 2 ...................................................................... 96
8.1 System design and technology ............................................................................................ 96
8.2 Anatomy of a Modern System ............................................................................................ 96
8.2.1 Server.................................................................................................................................. 97
8.2.2 Networks ............................................................................................................................ 97
8.2.3 Software ............................................................................................................................. 98
8.2.4 Protocols ............................................................................................................................. 99
8.2.5 Firewalls ............................................................................................................................ 100
8.2.6 Virtual private network (VPN) .......................................................................................... 100
8.3 Architectural Concepts...................................................................................................... 100
8.4 Software as a service (SaaS) .............................................................................................. 100
8.5 Web service ...................................................................................................................... 101
8.6 Distributed Architectures .................................................................................................. 101
8.7 Architectural Diagrams ..................................................................................................... 103
8.8 Designing Application Components................................................................................... 104
8.9 Deployment diagram ........................................................................................................ 107
CHAPTER 8 EXERCISES ............................................................................................................ 109
CHAPTER 9: System Analysis Problems .......................................................................... 111
9.1 System analysis theory ..................................................................................................... 111
9.2 Activity diagram................................................................................................................ 111
9.3 Use case diagram and description ..................................................................................... 112
9.4 Domain class..................................................................................................................... 112
9.5 State machine diagram ..................................................................................................... 112
CHAPTER 10: User and System Interfaces ...................................................................... 113
10.1 User interface design ...................................................................................................... 113
10.2 Understanding the User Experience and the User Interface............................................. 113
10.3 Transitioning from Analysis to User-Interface Design ...................................................... 116
CHAPTER 10 EXERCISES........................................................................................................... 120
CHAPTER 11: Approaches to System Development-1 ..................................................... 122
11.1 The System Development Life Cycle (SDLC) ..................................................................... 122
11.2 Predictive approach to the SDLC ..................................................................................... 122
11.3 Adaptive approach to the SDLC ....................................................................................... 123
11.4 Traditional Predictive Approaches to the SDLC ................................................................ 123
11.6 Waterfall model .............................................................................................................. 124
11.7 Modified Waterfall model ............................................................................................... 124
11.8 Adaptive Approaches to the SDLC ................................................................................... 125
CHAPTER 12: Approaches to System Development-2 ..................................................... 128
12.1 Methodologies, Models, Tools, and Techniques .............................................................. 128
12.2 Agile Development ......................................................................................................... 129
CHAPTER 13: Object-Oriented Design ............................................................................ 133
13.1 Overview of Object-Oriented Programs .......................................................................... 133
13.2 Analysis Models to Design Models .................................................................................. 134
13.3 Introduction to the Design Models .................................................................................. 135
13.4 Steps of Object-Oriented Design ..................................................................................... 136
13.5 Design class stereotype ................................................................................................... 138
13.6 Design Class Notation ..................................................................................................... 139
13.7 Developing the First-Cut Design Class Diagram................................................................ 141
13.8 Designing with CRC Cards ................................................................................................ 143
13.9 Fundamental Principles for Good Design ......................................................................... 145
CHAPTER 14: Advanced Systems Design Concepts ......................................................... 149
14.1 Object-Oriented Design with Interaction Diagrams ......................................................... 149
14.2 Use Case Realization with Communication Diagrams ...................................................... 149
CHAPTER 15: Use Case Realisations ............................................................................... 157
15.1 Use Case Realization with Sequence Diagrams ................................................................ 157
15.2 Good design principles .................................................................................................... 159
15.3 Developing a Multilayer Design....................................................................................... 159
15.3.1 Designing the View Layer ............................................................................................... 159

15.3.2 Designing the Data Access Layer .................................................................................... 160
15.3.3 Packaging the Design Classes ......................................................................................... 161
CHAPTER 16: System Operational-1 ............................................................................... 164
16.1 Testing ............................................................................................................................ 164
16.2 Test case and data .......................................................................................................... 165
16.3 Unit Testing .................................................................................................................... 165
16.4 Integration Testing.......................................................................................................... 167
16.4.1 Test the interface itself between the components. ....................................................... 167
16.4.2 Integration testing activities ........................................................................................... 167
16.5 System testing ................................................................................................................ 168
16.5 User Acceptance Testing (UAT) ....................................................................................... 168
17.1 Deployment Activities ..................................................................................................... 173
17.2 Converting and Initializing Data ...................................................................................... 174
17.3 Training Users ................................................................................................................. 175
17.4 Configuring the Production Environment ........................................................................ 176
18.1 Deployment Activities ..................................................................................................... 180
18.2 Direct Deployment .......................................................................................................... 180
18.3 Parallel Deployment ....................................................................................................... 181
18.4 Phased deployment ........................................................................................................ 181
CHAPTER 19: Current Trends in System Development-1 ................................................ 185
19.1 The Unified Process, Extreme Programming, and Scrum ................................................. 185
19.1.1 The Unified Process ........................................................................................................ 185
19.1.2 Unified Process Disciplines ............................................................................................. 187
19.1.3 UP Phase and Disciplines ................................................................................................ 188
19.1.4 UP Disciplines ................................................................................................................. 188
19.2 Extreme Programming (XP) ............................................................................................. 189
19.3 Scrum ............................................................................................................................. 192
CHAPTER 20: Current Trends in System Development-2 ................................................ 197
20.1 Gartner Top 10 Trends Impacting Infrastructure & Operations for 2020 .......................... 197

Content
This module aims to introduce to students the different system analysis techniques and
technologies for understanding and specifying what a computer-based information system
should accomplish. It examines the complementary roles of systems analysts, clients and users
in a system development life cycle. Students will learn different fact-finding techniques to elicit
system requirements and how to develop business models, data and process models, and object
models representing a system. Systems will also make use of a Computer Aided Software
Engineering (CASE) tool to build those models that capture the specifications of a system.
Module Aims
The aims of this module are to:
1. Analyse the complementary roles of different stakeholders including clients, users, and
analysts in the development of computer-based information systems.
2. Gather data to analyse and specify the requirements of a system using different fact-finding
techniques.
3. Perform analysis of computer-based information systems and present a system description

using different modelling approaches such as data and process models, business models,
and object models.
4. Demonstrate and appreciation of CASE tools such as an aid to systems modelling.
5. Work in a group to apply the knowledge and skills presented in this subject to typical
system analysis scenarios.

Learning Outcomes
On completion of this module, a student will be able to:
1. Show knowledge and understanding of:

i) The complementary roles of different stakeholders including clients, users, and
analysts in the development of computer-based information systems
ii) Concepts of system analysis and object-oriented development
iii) Concepts of agile development of computer-based information systems
2. Demonstrate module specific skills with respect to:

i) Identifying system requirements using different fact-finding techniques
ii) Performing analysis of computer-based information systems and presenting a
system description using different modelling approaches such as data and process
models, business models, and object models
iii) Designing and drawing class diagram, use case diagrams, sequence diagrams and
activity diagrams
Application of object-oriented analysis and design skills in implementing computer-
iv)
based information systems
v) Performing testing of computer-based information systems
3. Show cognitive skills pertaining to:

i) Demonstrating an appreciation of CASE tools as an aid to systems modelling
ii) The differentiation between various fact-finding techniques
iii) Build general and detailed models that assist developers in implementing computer-
based information systems
4. Demonstrate transferable skills in:

i) Analytical reasoning
ii) Self-management
iii) Problem formulation and decision making
iv) Working with others

Lesson Plan
Learning Outcomes
S/N. Topic
At the completion of this topic, students will be able to:
1. Introduction to 1. Discuss the software development and systems analysis
Systems Analysis and design
and Design 2. Explain the systems development life cycle
3. Explain the iterative development
2. Systems 1. Discuss the systems requirements
Requirements 2. Discuss the information-gathering techniques
3. Explain the documenting workflows with activity
diagrams
3. Use Cases 1. Explain:
a. Use case description
b. Use cases and user goals
c. Use cases and event decomposition
d. Use cases diagrams
4. Introduction to 1. Draw use cases using StarUML
CASE tool – a. UML diagramming
StarUML b. Use case diagram
c. Activity diagram
d. Class diagram
e. State machine diagram
f. Conceptual model
g. Sequence diagram
5. Domain Modelling 1. Understand conceptual model
2. Discuss class, association focusing on generalisation,
composition and aggregation
3. Describe the extending requirements models
4. Discuss the state machine diagram
6. Extending 1. Explain the use case descriptions
Requirements 2. Discuss the activity diagrams for use cases
Models 3. Describe design system inputs and outputs
4. Discuss the system sequence diagram
5. Explain the Use cases and CRUD
6. Describe the integrating requirements models
7. Essentials of 1. Explain the elements of design
Systems Design 1 2. Discuss the inputs and outputs for system design
8. Essentials of a. Explain system architecture
Systems Design 2 b. 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)

Lesson Plan
Learning Outcomes
S/N. Topic
At the completion of this topic, students will be able to:
9. User and System 1. Explain user-interface design concepts
Interfaces 2. Describe the transition from analysis to user-interface
design
3. Discuss user and system interfaces
4. Explain user-interface design
10. Approaches to 1. Discuss the systems development life cycle
System 2. Explain the support phase
Development-1
11. Approaches to 1. Discuss the SDLC methodologies, models, tools and
System techniques
Development-2 2. Explain Agile development
12. Approaches to 1. Discuss the difference approaches to software
System construction and modeling
Development-2
13. Object-Oriented 1. Discuss on the bridging from analysis to implementation
Design 2. Explain object-oriented architectural design
3. Explain the object-oriented detailed design
14. Advanced Systems 1. Explain the design with communication diagrams
Design Concepts 2. Design object-oriented and use case realisation
15. Use Case 1. Explain use case realisation with sequence diagrams
Realisations 2. Describe the MVC design pattern
16. System Operational- 1. Describe implementation activities
1 2. Describe various types of software tests (unit,
integration, usability, and performance and stress)
3. Explain how and why each software test is used
17. System Operational- 1. Describe the deployment activities
2 2. List various approaches to data conversion and system
deployment
3. Discuss the advantages and disadvantages of the
approaches
4. Describe training and user support requirements for new
and operational systems
18. System Operational- 1. Explain the difference types of deployment (direct,
3 parallel and phased)
19. Current Trends in 1. Describe the elements of the Unified Process (UP)
System 2. Compare and contrast the features of Extreme
Development-1 Programming and Scrum
4. Development
20. Current Trends in 1. Discuss the trends in technology infrastructure
System 2. Discuss the trends in application platform
Development-2

Teaching and Learning Methods
Students will learn through a combination of lectures, and practice and tutorial questions.
Students will be expected to learn independently by carrying out reading and directed study
beyond that available within taught classes.
Indicative Readings
Required Satzinger, J. W., Robert, J. B., & Stephen, B. D. (2016). Systems Analysis
Textbook and Design in a Changing World (7th ed.). Cengage Learning. ISBN: 978-
1305465268
Supplementary Pressman, R., & Maxim, B. (2015). Software Engineering: A Practitioner’s

Reading Approach (8th ed.). McGraw-Hill Education. ISBN: 978-0078022128
Sommerville, I. (2015). Software Engineering (10th ed.). Pearson Education.

ISBN: 978-0133943030
Robert, M. C. (2013). Agile Software Development, Principles, Patterns, and

Practices (1st ed.). Pearson Education. ISBN: 978-1292025940
Assessment/coursework
To satisfy module requirements, students must attain a minimal overall mark of 50 percent in the
module. Students are also required to comply with other examination and continuous assessment
policies stipulated in the programme handbook.
Specific for this module are the following requirements:

Weighting between components A and B - A: 40% B: 60%
Element Description % of Assessment
Component A (Controlled Conditions)
Test (120 minutes) 40%
Component B (CA: Continuous Assessment)
1. CA 1
60%
2. CA 2
Total (Component A + B) 100%

STUDY GUIDE
CHAPTER 1: INTRODUCTION TO
SYSTEMS ANALYSIS AND DESIGN
At the end of the chapter, students should be able to:
1. Discuss the software development and systems analysis and design

2. Explain the systems development life cycle
3. Explain the iterative development
1.1 System analysis

The main objective of system analysis activities is to fully understand what the new information
system should achieve. An information system is a set of computing components, both
hardware and software, that are interrelated to complete certain business transaction. System
analysis activities are performed by a System Analyst. The main job of a System Analyst is to
document down in details what the new information system must perform in order to achieve
the new business needs and requirements.
For example in a new customer management, the system must be able to store customer data,
track customer purchase, produce weekly report and many more other function in which each
function has many details. The job of the System Analyst is to fully understand those
requirements, document it down as details as possible before the system can be designed and
implemented.
1.2 Systems design

After the new information system requirements are gathered, the next step is to perform system
design. System design activities enable the System Analyst to transform the documented
requirements into details on how the information system can be implemented to achieve the
solution. The main objective of system design is to detail down how the system will actually
work. The activities include designing all the required components of the required system and
how all the components can be integrated together to achieve the final system solution.

STUDY GUIDE
1.3 Systems analysis and design

The focus of system analysis is to fully understand and document down what is required for
the new information system. Whereas system design is to figure out what components are
required for the new information system and how all the components operate together to
achieve the requirements.
To implement a middle to large scale business information system, programmers do not start
writing codes immediately after gathering the requirements. Many activities need to be carried
by a systems analyst prior to writing codes. The activities include planning, capturing the vision
of the new information system, understanding the details and designing the system using
various software design models.
Systems analysis and design process consists many tools (i.e. design models) and techniques
(i.e. SDLC, Agile and iterative development) that aids system analyst and software developer
to complete the information system development process.
1.4 The System Development Life Cycle (SDLC)

The System Development Life Cycle (or SDLC) is a framework that consists of the required
activities to understand, design, build, and deploy an information system. System maintenance
is an optional part of SDLC and is a discipline by itself.
The activities in a typical SDLC includes : Planning and project management, Systems
analysis, Systems design, Programming, Testing, User training and Deployment.
There are various approaches to a SDLC framework. The common approach is the “Six core
processes” listed below:
• 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
(Source: Satzinger, J. W., Robert, J. B., & Stephen, B. D. 2016)

STUDY GUIDE
There are also various approaches or development methodologies to implement the SDLC six
core processes. The development methodology is to provide a set of guidelines to carrying out
the activities for each SDLC core process. 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.
1.5 Agile Development

Information system 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 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. unexpected
• 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.
The six core processes are still involved in Agile development, but they are carried out
iteratively.
Agile development is 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. The six core development processes are repeated for each component.
Figure 1-1: Six Core Procsses


STUDY GUIDE
1.6 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. 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.
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.
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.
Developers choose components for each iteration based on priority, either the components most
needed or riskiest to implement.
Essential Reading
• Satzinger, J. W., Robert, J. B., & Stephen, B. D. (2016). Systems Analysis and Design
in a Changing World (7th ed.). Chapter 1.

STUDY GUIDE
CHAPTER 1 EXERCISES
Multiple Choice Questions
1. The main objective of system analysis activities is
A. decides on the software component required in the new information system

B. produce user interface design that the user like
C. to fully understand what the new information system should achieve.
D. conduct interview with the users of the new information system
2. The main objective of system design activities is
A. to fully understand what the new information system should achieve.

B. to code and implement the new information system
C. to design the user interface that is suitable
D. to detail down how the system will actually work
3. Which of the following statement about System Development Life Cycle is true?
A. System maintenance is a mandatory part of SDLC.

B. A framework that consists of the required activities to understand, design, build, and
deploy an information system.
C. There is only one single approach to SDLC
D. It is a strict rule that the system analyst should follow so as to ensure successful new
information system implementation.
4. Which of the following is not part of Agile development philosophy?
A. the plan must be strictly followed and cannot be changed

B. neither team members nor the users completely understand the problems and
complexities of a new system,
C. the project plan and the execution of the project must be responsive to unanticipated
issues.
D. It must have procedures in place to allow for, anticipate, and even embrace changes
and new requirements that come up during the development process.
5. Which of the following is not a benefit of Agile development?
A. Core functions that provide basic support for users, can be deployed in an early
iteration.
B. By dividing the system into subsystems, the most difficult problems can be identified
and addressed early in the project.
C. The whole system is deployed at the end of project deadline
D. By focusing on a subsystem at a time, the requirements are fewer and easier to solve.

STUDY GUIDE
Discussion Questions
1. State the work to be done in system analysis and system design.
2. What is the difference between systems analysis and systems design?
3. You are tasked to develop a Mobile App for a new Bubble Tea Store.
Perform the systems analysis for the new Mobile App.
Group in a team of four or five persons.

Assign the following roles to each person:
• Manager
• Barista
• Potential customers
• System Analyst for the new Mobile App.
The System Analyst conducts interviews with the store owner, barista, and potential
customers to understand the business needs.
System Analysis:
Based on the interviews, capture the vision, and produce a System Vision Document.
(See example below)

STUDY GUIDE
Sample System Vision Document:
Ridgeline Mountain Outfitters (RMO) is a large retail company that specializes in clothing
and related accessories for all types of outdoor and sporting activities. The mountain and
western regions of the United States and Canada witnessed tremendous growth in recreation
activities in recent years, including skiing, snowboarding, mountain biking, water skiing, jet
skiing, river running, sailing, jogging, hiking, cycling, camping, mountain climbing, and
rappelling. With the increased interest in outdoor sports, the market for winter and summer
sports clothing and accessories exploded, so RMO continually expanded its line of
sportswear to respond to this market.

STUDY GUIDE
CHAPTER 2: SYSTEMS REQUIREMENTS

1. Discuss the systems requirements

2. Discuss the information-gathering techniques
3. Explain the documenting workflows with activity diagrams
2.1 System analysis

System analysis is the third core process, and the main focus is to discover and understand
the details.
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.
Figure 2-1: Analysis Activities


STUDY GUIDE
2.1.1 Gather detailed information

A systems analyst obtains 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. Trying to understand an existing
system by identifying and understanding activities of all the current and future users
The system analyst must become an expert in that business area. For example, to implement a
loan-processing system, the system analyst needs to become an expert on the rules used for
approving credit. The most successful system analyst become experts in their organization’s
main business.
2.1.2 Define Requirements

Define requirement is to gather 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).
• 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.
2.1.3 Prioritize Requirements

This activity 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.
Scope Creep happens because 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 refinecontain
those parts of the system.
wide moon man tr
2.1.4 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 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).
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.
STUDY GUIDE
2.1.5 Evaluate Requirements with Users

System analyst 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.
2.2 System Requirements

System requirements includes 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.
2.2.1 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
2.2.2 Non-functional requirements

Characteristics of the system other than those activities it must perform or support.
Can be summarised as URPS: usability, reliability, performance, and security.
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.
Reliability requirements
How often a system exhibits such behaviours as service outages and incorrect processing and
how it detects and recovers from those problems.
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

STUDY GUIDE
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.
2.3 Stakeholders
Stakeholders are 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. 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.
2.4 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
2.4.1 Interviewing users and other stakeholders

Effective way to understand business functions and business rules. Most time- consuming and
resource-expensive option. System analyst 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.
2.4.2 Distributing and collecting questionnaires

Enable system analyst 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.

STUDY GUIDE
2.4.3 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.
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.
differences
• However, procedure documents frequently are not kept up to date, and they commonly
include errors. SA should review them with the users.
2.4.4. 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.
2.4.5 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.
2.4.6 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

STUDY GUIDE
2.5 Documenting Workflows with Activity Diagrams

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
Figure 2-2: UML Models diagram

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.

STUDY GUIDE
Figure 2-3: Activity diagram basic symbols

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.
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.

STUDY GUIDE
Figure 2-4: Order fulfillment process

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.

STUDY GUIDE
Figure 2-5: Ordering a product that has to be manufactured to match customer

specifications.
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. After
Engineering develops the specifications, two concurrent activities happen: Purchasing orders
the materials, and Production writes the program for the automated milling machines. 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.Finally, Scheduling puts the order on the Production schedule
Essential Reading

STUDY GUIDE
CHAPTER 2 EXERCISES
1. What is Scope Creep?

A. The client budget for the project is out of control
B. The system requirements completely change in the mid of the project implementation.
C. The system requirements tend to expand as users make more suggestions.
D. The system requirements freeze after the client sign the contract
2. The simplest way to get user feedback is via

A. User Interface Dialogs
B. Detailed system requirements documentation
C. Use case description
D. UML models
3. How should system analyst evaluate Requirements with Users?

A. Beginning of the project implementation
B. In the middle of project implementation
C. At the final phase of project implementation
D. Frequently and iteratively
4. The requirement "the menu should be loaded within two seconds" is what type of non-
functional requirement?
A. Security requirements
B. Performance requirements
C. Reliability requirements
D. Usability requirements
5. The requirement "the user interface must be intuitive to use" is what type of non-
functional requirement?
A. Performance requirements
B. Security requirements
C. Usability requirements
D. Reliability requirements

STUDY GUIDE
1. Why is developing a User Interface prototype important?
2. Based on the Bubble Tea Store System Vision Document and Summary,
a. State the functional requirements
b. State the non-functional requirements
Sketch the activity diagrams for the customer to order a bubble tea at the shop using
the Mobile App. Customer will get alerted on the Mobile App when the bubble tea is
ready for collection.
Extra scenario:
Customer is to pay by ePayment system.
Members get 10% discount

STUDY GUIDE
CHAPTER 3: USE CASES

1. Explain:
a. Use case description
b. Use cases and user goals
c. Use cases and event decomposition
d. Use cases diagrams
3.1 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.
3.2 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.
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>.”
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.”
3.3 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.

STUDY GUIDE
3.3.1 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).
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.
Figure 3-1: User Goal Technique and resulting use cases

3.3.2 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.
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.

STUDY GUIDE
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.
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.
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 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 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.

STUDY GUIDE
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.
o Example, If a customer bill has not been paid within 15 days, the system might
send a late notice.
o The temporal event “Time to send late notice” might be defined as a point 15
days after the billing date.
Temporal events are usually 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 is 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

STUDY GUIDE
3.4 Perfect technology assumption

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 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.
Events should be included during analysis only if the system would be required to respond
under perfect conditions:
Example of perfect conditions:
• equipment never breaking down,
• capacity for processing and storage being unlimited,
• people operating the system being completely honest and never making mistakes
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.
3.5 Event Decomposition to identify use cases

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.
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.
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.

STUDY GUIDE
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.
3.6 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.
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.
Figure 3-2: 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. The connecting line
between the actor and the use case indicates that the actor is involved with that use case.
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.

STUDY GUIDE
Figure 3-3: Customer Account Subsystem – All Actors

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.

STUDY GUIDE
The next Use case diagram illustrates this viewpoint, showing all the use cases involving the
customer for the Sales subsystem.
Figure 3-4: Sales Subsystem – Actor: Customer


STUDY GUIDE
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.
Figure 3-5: Sales Subsystem – Actor: Service and Store Representative


STUDY GUIDE
3.7 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.
Figure 3-6: Sales Subsystem – Fill Shopping Cart <<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. 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.

STUDY GUIDE
3.8 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.
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.
Essential Reading

STUDY GUIDE
CHAPTER 3 EXERCISES
1. Which of the following is the standard template for a user story?

A. “I want to <goal or desire> as a <role played>, so that <reason or benefit>.”
B. “As a <role played>, I want to <goal or desire>.”
C. “I want to <goal or desire> so that <reason or benefit>.”
D. “As a <role played>, I want to <goal or desire> so that <reason or benefit>.”
2. "Customer place an order" is what type of event?

A. temporal event
B. external event
C. state event
D. system event
3. Which of the events are usually automatically generated?

A. temporal event
B. external event
C. state event
D. system event
4. "The bank account balance is below a certain amount" is what type of event?
A. temporal event
B. external event
C. state event
D. system event
5. Which of the following assumption should system analyst make during system analysis?
A. Perfect technology assumption
B. Perfect user assumption
C. Perfect requirements assumption
D. All of the above

STUDY GUIDE
1. What is the perfect technology assumption? Why is it a useful assumption?
2. Based on the Bubble Tea case study, use either user goal or event decomposition
technique, write the user stories for the following actors:
• Manager
• Barista
• Potential customers
a. Identify the Uses Cases from the user stories

b. Draw the Use Case diagram.

STUDY GUIDE
CHAPTER 4: Introduction to CASE tool –

StarUML™
1. Draw use cases using StarUML™

• UML diagramming
• Conceptual model
• Use case diagram
• Activity diagram
• Class diagram
• State machine diagram
• Sequence diagram
4.1 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. Download at
https://staruml.io/
4.2 User case diagram

A use case diagram summarises the system users (i.e. the actors) and their interaction with
the system.
Figure 4-1: Use Case example


STUDY GUIDE
4.3 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.
Figure 4-2: Activity diagram example


STUDY GUIDE
4.4 Class diagram

The class diagram is a graphical notation of the structure of various classes in the system and
how they are related to each other. It also shows the details of each class like the attributes
and methods.
Figure 4-3: Class diagram example 1

Figure 4-4: Class diagram example 2


STUDY GUIDE
4.5 State machine diagram

State machine diagram is to describe state of an object, especially an entity object. An
object responds differently to the same event depending on what state it is in. It is typically
used in conjunction with sequence diagrams.
Figure 4-5: Sate machine diagram example

4.6 Sequence diagram

Sequence Diagrams are interaction diagrams that detail how operations are carried out.
They capture the interaction between objects in the context of a collaboration. Sequence
Diagrams are time focus and they show the order of the interaction visually by using the
vertical axis of the diagram to represent time what messages are sent and when.
Figure 4-6: System Sequence diagram example


STUDY GUIDE
Figure 4-7: Sequence diagram example

Essential Reading

STUDY GUIDE
CHAPTER 4 EXERCISES
1. Which of the following diagram can be used to summarises the system users (i.e., the
actors) and their interaction with the system?
A. Activity diagram
B. Use case diagram
C. Class diagram
D. State machine diagram
2. Which of the following diagram can be used to document the business flow process?
A. Class diagram
B. State machine diagram
C. Activity diagram
D. Sequence diagram
3. Which of the following diagram is used to document the structure of various classes?
A. Activity diagram
B. State machine diagram
C. Sequence diagram
D. Class diagram
4. Which of the following diagram is used to document the state of an object when an event
occurs ?
A. Activity diagram
B. Class diagram
C. State machine diagram
D. Sequence diagram
5. Which of the following diagram is used to document the interaction between objects to
complete a task?
A. Sequence diagram
B. Activity diagram
C. Class diagram

STUDY GUIDE
Draw all the UML diagrams (Figure 4-1 to 4-7) using StarUMLTM.
1. Use Case diagram

2. Activity diagram
3. Class diagram
4. State Machine diagram
5. Sequence diagram

STUDY GUIDE
CHAPTER 5: Domain Modelling

1. Understand conceptual model

2. Discuss class, association focusing on generalisation, composition and aggregation
3. Describe the extending requirements models
4. Discuss the state machine diagram
5.1 Domain classes (data entities)

“Things” end users deal with when they do their work. Example, 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.
5.1.1 The Brainstorming Technique

Analysts 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.
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.
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.
Figure 5-1: Brainstorming technique

STUDY GUIDE
5.1.2 The Noun Technique

A noun is a person, place, or thing. Identifying nouns help to identify what needs to be stored
by the system.
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.
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.
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?
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?
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.

STUDY GUIDE
5.2 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 and What to ignore
Figure 5-2: 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 and
address
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).
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.
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.
STUDY GUIDE
Figure 5-3: Examples of attributes of a customer

5.3 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.
In database management, the term relationship is association in UML and 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
• 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
On a class diagram, rectangles represent classes
Figure 5-4: Examples of Class diagram


STUDY GUIDE
On a class diagram, lines connecting the rectangles show the associations among classes.
Figure 5-5: Class association

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
Figure 5-6: Summary of multiplicity notation

Another example of a domain model class diagram, this one for the bank with multiple
branches
Figure 5-7: Example of banking domain model class diagram

STUDY GUIDE
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.
Figure 5-8: Example of college domain model class diagram

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.
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.
Figure 5-9: Example of college domain model with association class diagram
A dashed line connects the association class with the association line between the
CourseSection and Student classes. 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. 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.

STUDY GUIDE
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.
Another example of a domain model class diagram with a many-to-many association
Figure 5-10: Example of band domain model class diagram

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.
The analyst discovers additional information about the booking that needs to be captured and
remembered by the system.
Figure 5-11: Example of band domain model with association class diagram
An associative class named Booking that includes attributes: dateBooked, performanceOrder

and basePay.
Reading from Band to Concert, one band has many booking—each with its dateBooked etc.
Each booking applies to one concert.Reading from Concert to Band. One concert has many
booking—each with its dateBooked etc. Each booking applies to one band

STUDY GUIDE
5.4 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
5.4.1 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. 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.
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.
Figure 5-12: Example of super and sub class diagram

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

STUDY GUIDE
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.”
Figure 5-13: A partial domain model for a retail business

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.
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.
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.

STUDY GUIDE
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.
Figure 5-14: A bank model with abstract and concrete class

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.

STUDY GUIDE
5.4.2 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.
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)
Figure 5-15: Aggregation and Composition

Whole-part relationships—aggregation and composition—mainly allow the analyst to express

subtle distinctions about associations among classes.
Figure 5-16: Composition

Figure 5-17: Aggregation


STUDY GUIDE
5.5 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 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.
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.
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.
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.
Figure 5-18: State machine diagram


STUDY GUIDE
Pseudostate is 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 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.
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 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 whenever the guard becomes
true, the transition occurs.
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.
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.
Concurrent States is when nn 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.
Figure 5-19: State machine diagram with concurrent states


STUDY GUIDE
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.
a. 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.
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.
5.5.1 Example to develop state machine diagrams: 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.
Second step
• identify exit transitions for each of the status conditions
Figure 5-20: State machine state and transition causing exit

Third step:
• Combine the state-transition pairs into fragments
• Build a state machine diagram with the states in the correct sequence
Figure 5-21: Partial State machine state

STUDY GUIDE
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.
fifth step:
• look for additional transitions.
• a transition from Open to On back order.

sixth step
• complete all the transitions with correct names, guard- conditions, and action-
expressions.
Figure 5-23: Completed State machine state

seventh step
• quality-review step.
• reviewing and testing the state machine diagram

STUDY GUIDE
5.5.2 Example to develop state machine diagrams: InventoryItem

First and Second steps:
• identify the possible status conditions that might be of interest.
• identify exit transitions for each of the status conditions
Figure 5-24: State machine state and transition causing exit

Third and fourth steps:

• combine these states and transitions into fragments and connect them together to give
the first-cut state machine diagram.

Fifth step
• See if these state-transition fragments are really concurrent paths.
• In this case, two concurrent paths.
Path 1
Path 2


STUDY GUIDE
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.

• reduceInventory transition.
o InventoryItem will receive this message every time an item is sold.
o 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.
o Add guards to define those conditions.
o Also initiate a reorder process when the InventoryItem goes to a Low stock or
a Zero stock state.
• 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.
• 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.
Figure 7-4: Completed State machine state

STUDY GUIDE
5.6 Benefits of state machine diagram

It 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.
Essential Reading

STUDY GUIDE
CHAPTER 5 EXERCISES
1. What is main use of "The Brainstorming Technique"?
A. To discover business process.

B. To discover domain class.
C. To gather ideas and opinions on system requirements.
D. To document the use case description.
2. Which of the following best describe "The None Technique"?

A. Using the use cases, actors, and other information about the system, including inputs
and outputs to identify all nouns.
B. Analysts ask the users to discuss the types of “things” they work with routinely.
C. Analysts speculate the types of “things” the user works with routinely.
D. The users list out a list of None for the Analysts.
3. Super and sub class is shown using which type of relationship?

A. Association
B. Whole-Part
C. Multiplicity
D. Generalization/specialization
4. If two classes can exist separately, the whole-part relationship is?

A. Composition
B. Accumulation
C. Aggregation
D. Summation
5. What is a state machine transition?

A. The transformation of object datatype from one to another.
B. The movement of an object from one state to another state.
C. The change of object name in state machine.
D. The state of object creation and destroy.

STUDY GUIDE
With reference to the Bubble Tea Store case study.
1. Identify the domain model classes.

2. Draw the domain model class diagram.
Analysis the workflows for the bubble tea ordering process.

Draw the state machine diagram for an order.
Bubble tea order process. (in store)

Once an order is received the status is “New Order”.
The Barista can Accept or Reject the order.
If the order is Rejected, the status is “Order Cancelled” and the process ends.
If the order is Accepted, the status is “Preparing Order”.
Once the bubble tea is prepared, the status is “Ready for Collection”
When the customer collects the order, the status is “Order Collected” and the process
ends.
Bubble tea order process. (online)
Once an order is received the status is “New Order”.

The Barista can Accept or Reject the order.
If the order is Rejected, the status is “Order Cancelled” and the process ends.
If the order is Accepted, the status is “Preparing Order”.
Once the bubble tea is prepared, the status is “Waiting for delivery”.
When the rider collected the bubble tea the order becomes “Dispatched”.
At this point there is a new delivery status in concurrent with “Dispatched”.

When the rider collected the bubble tea the delivery status becomes “On the way”.
When the rider reached the destination the the delivery status becomes “Reached”.
If the delivery is successful, is becomes “Delivery success”.
If the delivery is unsuccessful

STUDY GUIDE
CHAPTER 6: Extending Requirements Models

1. Explain the use case descriptions

2. Discuss the activity diagrams for use cases
3. Describe design system inputs and outputs
4. Discuss the system sequence diagram
5. Explain the Use cases and CRUD
6. Describe the integrating requirements models
6.1 Use Case Descriptions

Use case descriptions is 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 tend to be written at two separate levels of detail: brief
description and fully developed description. A brief description should have 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.
Figure 6-1: Use cases and brief 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. There is no standard format, and many different formats are
available. 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.

STUDY GUIDE
Figure 6-2: Fully developed description sample

Figure 6-3: Fully developed description sample


STUDY GUIDE
Scenarios (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.
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.
Postconditions
Identify what must be true upon completion of the use case. It indicates 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.
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.

STUDY GUIDE
6.2 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.
Figure 6-4: Activity diagram for Create customer account


STUDY GUIDE
Figure 6-5: Activity diagram for Ship Items use case

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

STUDY GUIDE
Figure 6-6: Activity diagram for Fill shopping cart

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.

STUDY GUIDE
6.3 The System Sequence Diagram

Object-oriented approach is the flow of information is achieved through sending messages to
and from actors and back and forth between internal objects.
A system sequence diagram (SSD) describes flow of information into and out of the
automated portion of the system. It documents the inputs and the outputs and identifies the
interaction between actors and the system. It is an 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.
Figure 6-7: 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 labelled 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.
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.
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 is labeled to
describe its purpose and any input data being sent. The name should follow the verb-noun
syntax to make the purpose clear.

STUDY GUIDE
The returned value is 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.
A note can be added to any UML diagram to add explanations.
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.
Figure 6-8: SDD with loop frame

Alternate notation for loop can be presented using

[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.
Figure 6-9: SDD with alternate notation

STUDY GUIDE
The opt frame is used when a message or a series of messages is optional or based on some
true/false condition.
Figure 6-10: SDD with Opt frame

The alt frame is used with if-then-else logic.
Figure 6-11: SDD with Alt frame


STUDY GUIDE
6.4 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. 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.
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.
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.
Figure 6-12: Identify the input messages from activity diagram


STUDY GUIDE
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.
Figure 6-13: Describe the message

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
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.
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.

STUDY GUIDE
6.5 Use Cases and CRUD

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.
Take already identified use cases and verify that there are use cases for create, read, update,
and delete as a cross-check.
Figure 6-14: Customer CRUD

Summarize all use cases and all data entities/domain classes to show the connection between
use cases and data.
Figure 6-15: CRUD table showing use cases and corresponding domain classes
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.
STUDY GUIDE
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. The Adjustment class will require use cases to update, report, and delete
Adjustment objects.
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.
6.6 Integrating Requirements Models

Iterative approach state that only constructs 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
modelled in detail.
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.
Construction of a diagram depends on information provided by another diagram.

Development of a new diagram often helps refine and correct a previous diagram.

STUDY GUIDE
Figure 6-18: Relationships among object-oriented 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.
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.
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.
The detailed descriptions either in use case description or in activity diagrams, provide
important internal documentation of the use cases. It must completely support the use case
diagram. It is 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.
Essential Reading

STUDY GUIDE
CHAPTER 6 EXERCISES
1. Which part of use case description identify what the state of the system must be for the
use case to begin?
A. Flow of activities
B. Scenarios
C. Preconditions
D. Postconditions
2. Which part of use case description identify the steps performed by the actor and the
responses required by the system?
A. Preconditions
B. Postconditions
C. Scenarios
D. Flow of activities
3. Which of the diagram describes flow of information into and out of the automated portion
of the system?
A. System sequence diagram

B. Use case diagram
C. Activity diagram
D. Information diagram
4. Which type of frame can be used in System sequence diagram to represent repetition?
A. opt frame
B. loop frame
C. alt frame
D. empty frame
5. Which type of frame can be used in System sequence diagram to represent if else logic?
A. loop frame
B. opt frame
C. alt frame
D. empty frame

STUDY GUIDE
With reference to the Bubble Tea Store “Place Order” User Story.
1. Write the Use case description for “Place Order” Use case that has actors: Customer,
Order subsystem and Barista. Remember to include the alternative activity and
exception conditions (if any).
2. Draw the Activity Diagram for “Place Order” Use case.
3. Draw the System Sequence Diagram for the “Place Order” Use case between the
Customer, Ordering Processing System and Barista.
Customer User story

Order subsystem
• As a customer, I want to view the menu so that I can choose from a range of BBT
items.
• As a customer, I want to be able to customise the BBT items with range of tea bases,
size, toppings, sugar level, ice level, special instructions so that I can customise to my
preference.
• As a customer, I want to view the shopping cart to check and update order before
placing the order.
• As a customer, I want to be able to use e-Payment so that I can use methods like
Apple Pay, Google Pay or PayLah! to pay for the order.
• As a customer, I want to place the order for BBT items, so that I can complete order.
Order subsystem (in store)

• As a customer, I want to get notified on my app when the BBT is ready so that I can
go shopping for a while ? I can play game for awhile.
Order subsystem (At home, delivery)

• As a customer, I want to choose the collection or delivery time, and provide delivery
address so that it can be picked up or delivered at preferred timing and location.
• As a customer, I want to track the order status and track the shipment, so that I can
know when my order is prepared and when is the estimated collection or delivery
time.

STUDY GUIDE
CHAPTER 7: Essentials of Systems Design 1

1. Explain the elements of design

2. Discuss the inputs and outputs for system design
7.1 Systems Design

Analysis provides the starting point for design, the 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, which are the inputs to system design.
• Domain class diagrams,
• Use case diagrams,
• Use case descriptions,
• Activity diagrams,
• System sequence diagrams,
• State machine diagrams.
System Design is also a model-building activity. Designers convert the information gathered
during analysis, that is 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

STUDY GUIDE
Figure 7-1: Requirements and Design Models


STUDY GUIDE
7.2 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.
Figure 7-2: Design activities

System developers often ask themselves these questions to help them stay focused on the
objective of each design activity.

STUDY GUIDE
7.2.1 Describe the Environment

Describing the environment is the first design activity. Note the system analyst “Describes”
the Environment and not “Design” the Environment. Often the system analyst 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
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
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.
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.
7.2.2 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.
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.
STUDY GUIDE
Figure 7-3: Package and Deployment diagram


STUDY GUIDE
7.2.3 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.
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
7.2.4 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.
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.

STUDY GUIDE
7.2.5 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
Figure 7-4: Class diagram


STUDY GUIDE
7.3 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.
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.
Essential Reading

STUDY GUIDE
CHAPTER 7 EXERCISES
1. Which of the following is a input to the system design activities

A. Design class diagram
B. Package diagrams
C. Activity diagrams
D. Component diagrams
2. Which of the following is a product from system design activities

A. Activity diagrams
B. Design class diagram
C. Use case diagram
3. Why system analysts often need to Describes instead of Design the Environment?
A. Environment cannot be designed and can only be described
B. It is the task of system architect to design the environment.
C. It is easier to describe the environment.
D. System analyst needs to work with what is currently existing in the organisation.
4. Which of the following is not part of Design activities?

A. Design user interface
B. Design the database
C. Understand user requirements
D. Design the software classes and methods
5. Which of the following activity deal with how a user will interact with the system?
A. Design user interface
B. Describe the environment
C. Design the database
D. Design the software classes and methods

STUDY GUIDE
With reference to the Bubble Tea Store case study.
1. Answer the Questions in “Describing the Environment”. (note not all questions are
relevant)
2. Plan and design the first draft of the User Interface.

Use the System sequence diagram and Activity diagram from the Analysis stage as a
guide to figure out what are the User Interfaces to design.
• State the “Views” to be done and the fields in each “View”.
• Create a story board to link those “Views” together
• Write a short description for each view
o who is the user,
o how the user is going to use the view
o for what purpose etc.
• Detail design (e.g. colour scheme, where to place what) are not required.

STUDY GUIDE
CHAPTER 8: Essentials of Systems Design 2

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))
8.1 System design and technology

Requirements defined during analysis activities are stated in a technologically and
architecturally neutral way and 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 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.
8.2 Anatomy of a Modern System

The following diagram shows a Web-based system which is a simplified architectural
diagram for the Amazon.com shopping application.
Figure 8-1: Amazon.com shopping application.


STUDY GUIDE
The 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.
8.2.1 Server
Server is a computer or group of computers that manages shared resources such as file
systems, databases, and Web sites. It enables users and other computers to access those
resources over a network. 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.
8.2.2 Networks
The true power of modern computing lies in the ability to interconnect them.
Computer network is 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
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.
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.
The World Wide Web ( WWW or Web) is 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. Web resources are static documents: web pages, images, videos, e-mail and
other messages, software-based services such as shopping sites and online games.
Uniform Resource Locator (URL) is to identify Web resources it composed of three parts:
Figure 8-2: Uniform Resource Locator (URL)

STUDY GUIDE
Hyperlink embeds 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.
8.2.3 Software
There are two types. Application software and System software.
Application software is 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.
System software is 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. System software also includes database management systems, Web
browsers, Web server software.
Figure 8-3: Software in a system

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 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

STUDY GUIDE
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. 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.
8.2.4 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.
Figure 8-4: Protocols in a system

Network protocols enable accurate message transmission among the various computers and
software components. It 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. It is implemented within all computers and
network hardware devices.
There are two types of Web Protocols: HTTP and HTTPS.
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.

STUDY GUIDE
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.
8.2.5 Firewalls
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.
8.2.6 Virtual private network (VPN)

VPN isolate sensitive communications between servers or between an organization’s own
employees and servers. It incorporates technologies Secure Sockets Layers, Transport Layer
Security, and secure IP, reliably identify senders and recipients, and encrypt network
messages sent among them.
8.3 Architectural Concepts

Technology architecture.
The set of computing hardware, network hardware and topology, and system software
employed by an organization. It 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. It deployed on a technology architecture by distributing application
components to specific hardware devices and connecting them via networks and protocols.
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.
8.4 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.

STUDY GUIDE
8.5 Web service

It is a software service accessed over the Internet using Web protocols. It is 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 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 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.
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.
8.6 Distributed Architectures

Client/Server Architecture
It 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.
Three-Layer Architecture
It is 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. It divides the
application software into three layers that interact, as shown
Figure 8-5: Three-Layer Architecture


STUDY GUIDE
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
Figure 8-6: Software layers

Interoperability
It 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. 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.

STUDY GUIDE
8.7 Architectural Diagrams

Location diagrams
Used to show the geographic placement of various system components, including hardware,
buildings, and users.
Figure 8-7: Location diagram

Network diagram
Shows how locations and hardware components are interconnected with network devices and
wiring.
Figure 8-8: Network diagram


STUDY GUIDE
Deployment Diagrams
Describes how software components are distributed across hardware and system software
components.
Figure 8-9: Deployment diagram

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.
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.
Software components in the application server communicate with the DBMS using SQL as
the primary protocol and database access language.
8.8 Designing Application Components

Application component is a well-defined unit of software that performs one or more specific
tasks. It is 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.
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.

STUDY GUIDE
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
Figure 8-10: Group A to C use cases


STUDY GUIDE
Figure 8-11: Group D use cases

Figure 8-12: Group E use cases


STUDY GUIDE
8.9 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
Figure 8-13: Design the View layer Application Component

• Figure 8-14: Deployment diagram with three-layer architecture

• (Source: Satzinger, J. W., Robert, J. B., & Stephen, B. D. 2016)

STUDY GUIDE
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.
Essential Reading

STUDY GUIDE
CHAPTER 8 EXERCISES
1. What type of software performs user or business-specific tasks
A. System software
B. Operating software
C. Application software
D. Database software
2. What is a set of languages, rules, and procedures that ensure accurate and efficient data
exchange and coordination among hardware and software components?
A. Networks
B. Protocol
C. Firewall
D. Server
3. Which of the following employs secure network protocols?
A. HTTP
B. URL
C. Server
D. HTTPS
4. Which of the following is a software distribution model in which a third-party provider

hosts applications and makes them available to customers over the Internet?
A. VPN
B. SaaS
C. Web Services
D. Client/Server Architecture
5. Which of the following diagram is used to show the geographic placement of various
system components, including hardware, buildings, and users?
A. Network diagram
B. Deployment diagram
C. Map diagram
D. Location diagram

STUDY GUIDE
With reference to the Bubble Tea Store case study use case diagram.
1. Identity the Application Component Boundary.

• State the Actor/Domain class/ Events for each use case
• Group all the similar use cases together
2. Using the Application Component Boundary, design the Deployment diagram using
three-layer architecture.
• View (User Interface
• Controller (Business logic)
• Model (Database)
Note: Each layer can be further divided into many packages.

STUDY GUIDE
CHAPTER 9: System Analysis Problems

1. Discuss system requirements
9.1 System analysis theory

a. What is meant by Agile Development and iterative development?
b. What is the purpose of a System Vision Document?
c. What are the benefits of doing vendor research during information-gathering

activities?
d. Explain why the Unified Modeling Language (UML) is important to use as a standard
for creating information systems models.
9.2 Activity diagram

The current employee leave application process works as follow:
• The Employee fills in the leave application form online with the following details.
o Start Date of leave
o End Date of leave
o Type of leave: Annual/Parental/Study
• 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 are start and end dates where the employee is not supposed
to take leaves.)
• 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.
Based the case study process flow, document the workflow by drawing the Activity
Diagrams.

STUDY GUIDE
9.3 Use case diagram and description

Below is the User Stories for employee leave application process in the employee leave
application process.
• 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.
1. Draw the use case diagram based on the above user stories.
2. One of the use case in the case study is “Apply Leaves”. Write the use case
description for “Apply Leaves”
9.4 Domain class

Design the domain class “Leaves Application Details”.
9.5 State machine diagram

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.
Draw the State machine diagram for the leave application process.

STUDY GUIDE
CHAPTER 10: User and System Interfaces

1. Explain user-interface design concepts

2. Describe the transition from analysis to user-interface design
3. Discuss user and system interfaces
4. Explain user-interface design
10.1 User interface design

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.
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.
User-interface design during Design activity utilizes other analysis models as input, e.g.
system sequence diagram. It produces models in the form of sample layouts that are used by
programmers to implement the final system.
User-interface design need to consider the entire user experience, what devices are being used
and what the users are doing on those devices. It also includes the type of device: desktop,
laptop, tablet, or smartphone, type of OS: iOS, Android or Windows devices.
10.2 Understanding the User Experience and the User

Interface
User Experience (UX) is a broad concept that applies to all aspects of a person’s interaction
with a product or service. It includes user actions, responses, perceptions, feelings
anticipation when using the software application.
User Interface (UI) is 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. It varies widely depending on such
factors as interface purpose, user characteristics, and characteristics of a specific interface
device. For example, for internal users the design for operational efficiency and can be
trained to use a specific interface optimized for a specific hardware device. For general
customer-accessible system we need to assume a cell phone as the input/output device and
the design is for general ease of use. User Interface must be integrated into all elements of the

STUDY GUIDE
system development. It should not be developed and added to the system near the end of the
development process.
Three important principles of user-centered design:
• Focus early and throughout the project on the users and their work.
• Evaluate all designs to ensure usability.
• Use iterative development.
Usability is 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.
The ease of learning and ease of use are in conflict. Examples of easy to learn are 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 is for internal users that use the system all day. It is important to
make the interface fast and flexible, with shortcuts, hot keys, voice commands, and
information-intensive screens. It might be harder to learn, but it will be easier to use after it is
learned.
Metaphors are 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. 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. It is widely applied to user-interface design.
Figure 10-1: Metaphors


STUDY GUIDE
Human-interface objects (HIOs) are objects that appear on a screen the user can manipulate.
For example: documents, buttons, menus, folders, and icons.
Affordance is to use HIOs that reflect their purpose or behaviour. It is mostly used in buttons
or other small icons. 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. It 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.
HIOs should provide visual feedback when activated. Visual or audio response by the system
in response to some user action and 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.
Consistency is the effectiveness of the user experience is highly dependent on consistency.

Different levels or areas where consistency should be maintained.
Another challenge is consistency versus continuity. Changes occurring in new releases of an

application. We should maintain a certain level of consistency over time across multiple
releases. The problem designers have is understanding how to add new functionality while
maintaining continuity across new releases. It 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.
Discoverability is the feature of the user interface that provides clues to help the users
uncover hidden features. Two ways to implement: use active discovery to help find hidden
features and use visual diagrams to help users discover functions or tools.
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.
Use visual diagrams to help users discover functions or tools. This is a simple diagram that is
very expressive of how to perform a desired action.
Figure 10-2: Visual diagram


STUDY GUIDE
Closure is based on the dialogue metaphor. It is 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). 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.
For readability and navigation, text should be readable (font type, size, and colour).
The navigation should be clear. It should 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. The input forms have a Cancel button to immediately back out of the specific form.
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.
For usability and efficiency, the entire user experience must be considered to make an
application effective and usable. It should provide shortcut keys to support experienced users.
It should design error messages that provide solution options and design for simplicity.
10.3 Transitioning from Analysis to User-Interface

Design
User-interface design built from use case descriptions, activity diagrams and system sequence
diagrams. For use case descriptions, grouping of related use cases to identify main menu
items as the starting point for a dialogue or form.
Menus provide the mechanisms first to organize use cases and to invoke a particular use case
or user dialogue. It is needed to present the user with a number of choices per screen, to
group related functions together so users can more easily locate them.
How many main menu items are required is the common question. It can be 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. Also allows for additional menu items, such as setting
options or preferences.
We can use the two methods to group use cases into one menu item. Method one is to group
use cases with common actors and Event decomposition. Second method is to group use
cases that implement CRUD actions for a specific domain class.
For example, an initial grouping of these cases by actor and subsystem is a good starting
point for menu design.

STUDY GUIDE
Figure 10-3: Group use cases into one menu item

Use cases grouped into first-cut menus by similar function and user
Figure 10-4: Group use cases into one menu item

STUDY GUIDE
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 and may enable multiple menu levels to be displayed at one time.
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 reasons we need to
start GUI design early.
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.
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.
Figure 10-5: 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.
After identifying all required dialogues, the designer lists 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 designer needs to consider design for different type of devices: Desktop and
Laptop User Interfaces, Web-Based Applications or Tablets.

STUDY GUIDE
Essential Reading

STUDY GUIDE
CHAPTER 10 EXERCISES
1. What is a broad concept that applies to all aspects of a person’s interaction with a product
or service?
A. User Experience
B. User Interface
C. User Design
D. User Survey
2. What is the set of inputs and outputs that directly involve an application user?
A. User Experience
B. User Interface
C. User Design
D. User Survey
3. What are items that appear on the screens are virtual entities.
A. Menu
B. Metaphors
C. Mouse pointer
D. Desktop
4. What is the feature of the user interface that provides clues to help the users uncover
hidden features.
A. Consistency
B. Continuity
C. Discoverability
D. Effectiveness
5. Consistency user interface is to be keep

A. Within and across Platforms
B. Within a suite of applications
C. Within each application
D. All of the above

STUDY GUIDE
With reference to the Bubble Tea Store Order Bubble Tea use case.
• Group the related use cases into menu items

• Decides on the menu choices for each menu item.
• Identify the dialogue/screens from the System Sequence Diagrams.
• Design all the identified dialogue/screens.
• Write a brief description for each dialogue/screen.
• Construct the storyboards using the dialogue or screen.
• Detail design (e.g. colour scheme, where to place what) are not required.

STUDY GUIDE
CHAPTER 11: Approaches to System

Development-1
1. Discuss the systems development life cycle

2. Explain the support phase
11.1 The System Development Life Cycle (SDLC)

The SDLC is 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.
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.
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.
Figure 11-1: Predictive to Adaptive SDLC

11.2 Predictive approach to the SDLC

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.

STUDY GUIDE
11.3 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.
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.
11.4 Traditional Predictive Approaches to the SDLC

Traditional Predictive Approaches to the SDLC can be grouped into six 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.
4. Design
Focuses on configuring and structuring the new system components. It uses 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.
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.
Figure 11-2: Support phase in SDLC

STUDY GUIDE
11.6 Waterfall model

Waterfall model assumes that the phases can be carried out and completed sequentially. The
phases of the project flowing down, one after another. 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.
Figure 11-3: Waterfall model

11.7 Modified Waterfall model

In modified waterfall model the project’s phases overlap, influencing and depending on each
other. Modified waterfall model is still predictive.
Figure 11-4: Waterfall model


STUDY GUIDE
11.8 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. One of these smaller parts is
analysed, designed, built, and tested during a single iteration; then, based on the results, the
next iteration proceeds to analyse, design, build, and test the next smaller part.
Figure 11-5: 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.
Incremental development is based on an iterative life cycle. The 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.
Walking skeleton provides a complete front-to-back implementation of the new system but
with only the “bare bones” of functionality. It is developed in a few iterations early in the
project. It adds on the “flesh” (i.e., more functions and capabilities) in later iterations. It 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.
Essential Reading

STUDY GUIDE
1. What is a useful way to categorise SDLC?
A. Either as Predictive or Adaptive

B. There is no way to categorise SDLC.
C. SDLC is only Predictive
D. Along a continuum from Predictive to Adaptive.
2. What is the assumption of Predictive approach?
A. The development project cannot be planned and organized and that the new
information system cannot be developed according to the plan.
B. The development project can be planned and organized but the new information
system cannot be developed according to the plan.
C. The development project can be planned and organized and that the new information
system can be developed according to the plan.
D. The development project can be planned and organized but the new information
system cannot be developed according to the plan.
3. What is the assumption of Adaptive approach?
A. The system’s requirements are not well understood.

B. The users’ needs are not well understood.
C. The project can’t be planned completely.
D. All of the above
4. Which phase is part of the overall SDLC, but not considered part of the initial
development project.
A. Support phase
B. Analysis phase
C. Design phase
D. Implementation phase
5. What provides a complete front-to-back implementation of the new system but with only
the “bare bones” of functionality?
A. Final implementation
B. Walking skeleton
C. Story board
D. Use case description

STUDY GUIDE
1. What are the advantages and disadvantages of iterative SDLC model?
2. Sketch and write a description of the layout of the school building.

Are both the sketch and the written description considered models of SIM building?
Which is more accurate? More detailed?
Which would be easier to follow by someone unfamiliar to SIM building?
Any iterative approach that you have used?
3. Describe a technique you use to make sure you get assignments done on time.
What are some of the tools you use with this technique? Any iterative approach that you
have used?

STUDY GUIDE
CHAPTER 12: Approaches to System

Development-2
1. Discuss the SDLC methodologies, models, tools and techniques

2. Explain Agile development
12.1 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 are the
guidelines for conducting a user interview, how to write user story and how to identify use
cases/domain class etc.
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.
The techniques, models, and tools support one another to provide a comprehensive,
integrated methodology.
Figure 12-1: System development Methodology

Methodologies used in a company can be developed by systems professionals within the

company based on their experience. It also can be learned and used based on purchased
materials and training from consulting firms or vendors. (e.g. IBM Rational). The
methodology a company adopts can be informal, ad hoc and almost undefined and can be
very chaotic. Management in IT departments should adopt a flexible methodology so it can
be adapted to different types of projects and systems.
Models are used to record or communicate information, a representation of an important

aspect of the real world (i.e., abstraction). Abstraction is to 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.
STUDY GUIDE
Models used in system development are 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 is the industrial standard for software models. Models used
in system development are use case diagram, domain model class diagram, design class
diagram, sequence diagram, package diagram, screen design template, dialog design
storyboard, entity-relationship diagram (ERD) and database schema.
Some project-planning model used to manage the development process are Gantt chart,
organizational hierarchy chart, financial analysis models—NPV, payback period, system
development life-cycle model, stakeholders list and iteration plan
Software tools are available support that helps create models or other components required in
the project. Examples of UML Tools are IBM Rational and StarUML. Example of project
management software tool is Microsoft Project.
Techniques are 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.
12.2 Agile Development

The 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, that is able to change directions rapidly, even in the
middle of a project.
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. It emphasises on taking an adaptive approach and
making it agile in all development activities and tasks.
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.
The manifesto for Agile Software Development” consists of four basic values or core
philosophy:
• Value responding to change over following a plan
• Value individuals and interactions over processes and tools
• Value working software over comprehensive documentation
• Value customer collaboration over contract negotiation

STUDY GUIDE
Some industry leaders in the Agile movement coined the term “chaordic to describe an Agile
project. It 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.
Another important aspect of Agile development is that customers must continually be

involved with the project team and becomes part of the technical team. Working software is
being developed throughout the project, customers are continually involved in defining
requirements and testing components.
The Agile Modelling Principles is not about doing less modelling, but about doing the right
kind of modelling at the right level of detail for the right purposes. It doesn’t dictate which
models to build or how formal to make those models. It helps developers stay on track with
their models by using them as a means to an end rather than end deliverables. It expresses the
attitude that developers should have as they develop software.
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
• 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
Essential Reading

STUDY GUIDE
1. What is the purpose of IBM Rational software?

A. Project management tool
B. Financial management tool
C. Human resource management tool
D. UML software modelling tool
2. What is the industrial standard for software models?
A. Dataflow language
B. Unified modelling language
C. Entity-relationship diagram
D. Standard software language
3. Which if the following about System development methodology is true?
A. It provides guidelines for every aspect of the system development life cycle.
B. It provides guidelines for some aspects of the system development life cycle.
C. It provides strict rules for every aspect of the system development life cycle.
D. It provides strict rules for some aspect of the system development life cycle.
4. Which of the following best describe software abstraction ?
A. Not easily understand by un-train people

B. Separate out an aspect that is of particular importance
C. Only show parts of the system
D. Separate out an aspect that is not importance
5. Which of the following is not the basic values of Agile Development?
A. Value individuals and interactions over processes and tools

B. Value working software over comprehensive documentation
C. Value following a plan over responding to change over
D. Value customer collaboration over contract negotiation

STUDY GUIDE
1. What is Agile development?
2. What are the four “values” reflected in Agile development?
3. What is Agile modeling?
4. What are some other techniques you use to help you to complete activities in your
life? How can you apply Agile values in this aspect?

STUDY GUIDE
CHAPTER 13: Object-Oriented Design

1. Discuss on the bridging from analysis to implementation

2. Explain object-oriented architectural design
3. Explain the object-oriented detailed design
13.1 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. It defines 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.
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.
Think of how people in a company from different department works together to run the
company. Each department is a layer (e.g. view, controller, model), a people is an object.
People communicate with each other, that is object calling another object method.
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. 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. 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.
Figure 13-1: An object-oriented program example

STUDY GUIDE
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)
and Database Access object (data layer).
13.2 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.
For each use case, the design models must provide the information required to
identify the classes and document the flow of execution (for coding of methods)
Diagram below shows the model building process flows from analysis to design to
implementation.
Figure 13-2: Analysis to Design Model


STUDY GUIDE
13.3 Introduction to the Design Models

Design class diagram is the 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.
Figure 13-3: Domain and Design class

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
System sequence diagrams (SSD) only used in analysis phase.Only two actors, the external
actor and the system. Sequence diagram expands the system object to identify the internal
interacting objects.
In sequence diagram, system object is no longer included,
Figure 13-4: A sequence diagram


STUDY GUIDE
A communication diagram provides basically the same information as sequence diagram, but
in different formats.
Figure 13-5: communication diagram

Class Responsibility Collaboration (CRC) provides a straightforward approach for detailed

object-oriented design, especially for simple use cases. It 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.
The 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.
Figure 13-6: CRC card

13.4 Steps of Object-Oriented Design

Object-oriented design normally has three separate layers: user interface, problem domain,
and database access layers. The process that identifies and describes the classes within each
layer. It 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.
For 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.

STUDY GUIDE
Figure 13-7: 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 class diagram contains the final definition of each class in the final object-oriented
software system. The primary source of information for this diagram is the domain model.
The domain model shows a set of problem domain classes and their associations. It serves as
the basis for database design, and for the software classes as defined in the design class
diagram. It is done in analysis stage, generally don’t worry much about the details of the
attributes
In design stage, enhance the domain model to get the Design class diagram. The 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). Need to define the methods and parameters that are passed to the
methods and the return values from methods.
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.

STUDY GUIDE
13.5 Design class stereotype

Stereotype is a way to categorize a model element as a certain type. It extends the basic
definition of a model element by indicating that it has some special characteristic to highlight.
The notation for a stereotype is «control». There are four types of standard stereotypes: an
entity class, a boundary or view class, a controller class, and a data access class.
Figure 13-8: Design class stereotype

Entity class design stereotype for a problem domain class. It is typically describes something
users deal with when doing their work. Objects of entity classes usually need to be
remembered. It is 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.
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.
Controller class mediates between the boundary classes and the entity classes. The
responsibility is to catch the messages from the boundary class objects and send them to the
correct entity class objects. It acts as a kind of switchboard between the boundary or view
layer and the domain layer.
Data access class is used to retrieve data from and send data to a database. It also called a
database access class. It is a separate layer of classes to access the database is often included
in the design. It separates the insert database access logic, including SQL statements, from
the entity class.

STUDY GUIDE
13.6 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 and Property.
Figure 13-9: Design class notation

Visibility denotes whether other objects can directly access the attribute. The + plus sign,
denotes public. The - minus sign denotes private. The # pound sign denotes protected.
The data-type-expression denotes the return datatype such as character, string, integer,
number, currency, or date. Can include initial-value, if applicable. Property (within curly
braces), such as {key}, if applicable
Method signature shows all the information needed to invoke (or call) the method. It shows
the format of the message that must be sent, which consists of these attributes: Method
visibility, Method-name, Method-parameter-list (incoming arguments) and 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.
Figure 13-10: Domain and Design Student class

Domain model includes attribute list contains all attributes discovered during analysis
activities. Class diagram includes more information on attribute types, initial values, and
properties and 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.

STUDY GUIDE
Class-level method refers to 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.
Generalization/specialization also known as 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.
The class-level (static) attributes are attribute that is underlined,
The abstract class is class name that is italic. (e.g. Sale). An abstract class that can never be
instantiated. It is to be inherited by other class. It provides a central holding place for all the
attributes and methods that each of the three subclasses will need
Figure 13-11: Completed Class diagram


STUDY GUIDE
13.7 Developing the First-Cut Design Class Diagram

First-cut design class diagram is developed by extending the domain model class diagram.
It Requires two steps:
1. add type and initial value information to the attributes (Elaboration of Attributes)
2. add navigation visibility arrows. (Navigation Visibility)
Figure 13-12: Partial Sales subsystem domain model class diagram

Elaboration of Attributes is fairly straightforward process. The 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.
Navigation Visibility is 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. “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. 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). Tthink of it as having a Sale object embedded within the
Customer object
Figure 13-13: Navigation Visibility

STUDY GUIDE
In 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.)
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.
• 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.
• 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.
Figure 13-14: First cut class diagram


STUDY GUIDE
Adding 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. It has
navigation visibility at the top of the visibility hierarchy and starts the use case by messaging
a customer. To elaborate attributes, add type information and visibility. To identify
navigation visibility, first identify which classes may be involved and then determine the
classes that require navigation visibility to other classes.
To identify navigation visibility in the example, 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.
13.8 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.
CRC card with lines that partition it into three areas: class name, responsibility, and
collaboration classes.
Figure 13-15: CRC card

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). And a stack of blank CRC-formatted index cards.
For each use case repeat these steps:

1. Select a use case.
• The first card to include should be a use case controller card.
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.

STUDY GUIDE
• 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.
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.
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.
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.
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)
Figure 13-16: Create customer account Use Case with CRC


STUDY GUIDE
Figure 13-17: Create customer account Use Case with CRC

13.9 Fundamental Principles for Good Design

In object responsibility, Each object should be responsible for carrying out a part of the
system processing. Responsibilities are categorized in two major areas: knowing and doing.
Knowing object’s responsibilities for knowing about its own data. Know how to maintain the
information in those attributes. Know where to go to get information when required and
navigation visibility and knowing about other classes with which it must collaborate to carry
out use cases.
Doing means all the activities an object performs to complete a use case. The 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.
Separation of responsibilities, also known as separation of concerns. It is a design principle

that is applied to a group of classes rather than to each class individually. The basic idea is to
segregate classes into packages or groupings based on a primary focus of processing
responsibility.
Separation of responsibilities is the fundamental principle behind multilayer design.

Multilayer design layers are 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. 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.

STUDY GUIDE
Protection from variations (change) means that parts of a system that are unlikely to change
should be segregated (or protected) from those that will change. It tries to isolate the parts
that will change from those that are more stable. It uses 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.
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. It is 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.
Coupling is 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.
Cohesion is 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. It is hard to maintain because they perform many different functions,
tend to be overly sensitive to changes within the system (ripple effects). Usually difficult to
understand, their functions are intertwined, and their logic is complex.
Essential Reading

STUDY GUIDE
1. For a very complex use case, which of the diagram is the most suitable?
A. CRC cards
B. Sequence diagram
C. Communication diagram
D. System Sequence diagram
2. What is the method to categorise a model element as a certain type?
A. Inheritance
B. Abstract
C. Stereotype
D. Static
3. Which type of class is never instantiated?
A. Static
B. Stereotype
C. Inheritance
D. Abstract
4. What is navigation visibility?
A. Ability of one object to interact with and send messages to another object.
B. Ability of one object to hide the implementation.
C. Ability of one class to be instantiated.
D. Ability of one class to be hidden.
5. Which of the following symbol is used to denote protected attribute?
A. minus
B. plus
C. pound
D. asterisk

STUDY GUIDE
A preliminary Customer Bubble Tea ordering app was written in Java for the user feedback.
1. Analysis the Java program.
2. Draw the prelim Design Class Diagram.

STUDY GUIDE
CHAPTER 14: Advanced Systems Design

Concepts
1. Explain the design with communication diagrams

2. Design object-oriented and use case realisation
14.1 Object-Oriented Design with Interaction Diagrams

Use case realization is 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. For example, 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.
Interaction diagrams are the heart of object- oriented design. Realization of a use case
determines what objects collaborate and the messages they send to each other to carry out the
use case (interaction diagram)
There are two types of interaction diagram: communication diagrams and sequence diagrams.
Communication diagrams is a little less detailed. It provides a broad “overview” picture of
the interactions. It works best for use cases that are not too large with many messages. It
provides a snapshot view of the classes and messages. The disadvantage are not much space
allowed for messages, can easily become cluttered with overlapping information.
Sequence diagrams provide more detailed and allow the designer to visually document the
process flow of the messages.
14.2 Use Case Realization with Communication

Diagrams
Communication diagram consists of actors, objects, links, and messages.
Figure 14-1: Communication diagram


STUDY GUIDE
The 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.
The Messages come into the system through data that is entered on forms. It comes
electronically by other external devices or systems.
Object is instantiated class objects that perform actions to help carry out the use case. It can
both receive messages and send messages. The object notation is a colon and underlining
Link connectors illustrate the flow of the messages. It shows where the messages flow.
Messages can flow in either direction on a link.
Message send from an object or actor to an object or actor. It is a request for service. It can
return data from a previous message. It invokes a service in an object. In programming terms,
a message is the same as a procedure call or a method call.
Message syntax is
[true/false condition] sequence-number:
return-value: = message-name (parameter-list)
The True/false condition is tested for true or false. If it is true, then the message is sent; if
false, the message is not sent. It only applies to sending the message. It is optional.
The sequence number is used to identify the order of the messages. It uses 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.
Return-value is 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.
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 “:=”.
Parameter-list contains items that are being passed to the destination object via the message.
In programming terms, these are the arguments.
The following diagram shows a prelim communication diagram for the Create customer
account use case.

STUDY GUIDE
Figure 14-2: Create customer account use case.

The asterisk between the number and the name indicates that the message may be sent
multiple times.
Figure 14-3: multiply occurring message

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. It is helpful to have either an activity diagram or a system sequence diagram
and a detailed use case description for the final design class diagram.
Figure 14-4: First-cut design class diagram for Create customer account
Figure 14-5: System sequence diagram for Create customer account


STUDY GUIDE
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.
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.
• 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.
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.
• 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.

STUDY GUIDE
Figure 14-6: Final communication diagram for Create customer account use case
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.
Figure 14-7: Design class diagram for methods added from Create customer account
STUDY GUIDE
Essential Reading

STUDY GUIDE
1. What are the two types of interaction diagrams?
A. communication diagrams and use case diagrams

B. communication diagrams and sequence diagrams
C. class diagrams and sequence diagrams
D. class diagrams and use case diagrams
2. Which of the following statement about Communication diagram is false?
A. It is very detailed.
B. Provides a broad “overview” picture of the interactions.
C. Works best for use cases that are not too large with many messages.
D. It provides a snapshot view of the classes and messages.
3. What represent 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?
A. Message
B. Object
C. Actor
D. Link
4. What comes into the system through data that is entered on forms. It comes electronically
by other external devices or systems?
A. Actor
B. Object
C. Link
D. Message
5. What is instantiated class objects that perform actions to help carry out the use case. It
can both receive messages and send messages?
A. Actor
B. Message
C. Object
D. Link

STUDY GUIDE
2. Select a few simple use cases (e.g. View Menu) and draw the Communication
Diagram.

STUDY GUIDE
CHAPTER 15: Use Case Realisations

1. Explain use case realisation with sequence diagrams

2. Describe the MVC design pattern
15.1 Use Case Realization with Sequence Diagrams

Design process for sequence diagrams is the same as communication diagrams. It starts with
System sequence diagram and first-cut design class diagram. Other models, such as a use
case description and activity diagram, are also helpful.
System sequence diagram only has two lifelines—one for the actor and one for the system.
Starting with the System sequence diagram, 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.
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. It has the same set of messages but displayed differently. The primary benefit of
the sequence diagram is the ability to lay out the messages from top to bottom to emphasize
the sequence of firing.
Figure 15-1: Communication diagram from Create customer account use case

STUDY GUIDE
Figure 15-2: Sequence diagram from Create customer account use case
Sequence Diagram has 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. Below each actor and object is a lifeline, which is used as an indicator of the
life of the object. Attached to locations of each lifeline are vertical boxes representing
activation lifelines. It is the time period when a method is executing. Messages are attached
to the lifeline either as a source point or a destination point.
There are two ways to indicate data being returned; by a return assignment with the “:=”
operator, or as a return message using a dashed arrow.
Figure 15-3: Return data in sequence diagram

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.

STUDY GUIDE
15.2 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.
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.
15.3 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.
15.3.1 Designing the View Layer

To add a view layer, following the steps:
1. Add an object for each input form or screen.
2. Add the appropriate messages from the Actor to the input «view» objects.
In the example below, messages are added for the :CustWindow to open the :AddrWindow,
and the :AddrWindow to open the :AcctWindow.
Figure 15-4: Add customer account use case with view layer added
STUDY GUIDE
15.3.2 Designing the Data Access Layer

The 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.
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.
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.
Figure 15-5: Designing the Data Access Layer


STUDY GUIDE
15.3.3 Packaging the Design Classes

Package diagram is a high-level diagram to associate classes of related groups. It separates
and group 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. This
information can be captured by showing each layer as a separate package. The classes are
placed inside the appropriate package based on the layer to which they belong.
Figure 15-6: Package Diagram

Dependency relationship is shown by 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.
Essential Reading

STUDY GUIDE
1. Primary benefit of the sequence diagram over communication diagram is the ability to
A. show object methods.

B. show the sequence of message firing
C. show the actor calling the object
D. lay out the messages from top to bottom to emphasize the sequence of firing.
2. Which of the following statement with regard to sequence diagrams is true?
A. Design process for sequence diagrams is not the same as communication diagrams.
B. Design process for sequence diagrams is the same as communication diagrams.
C. Design process for sequence diagrams almost the same communication diagrams.
D. Design process for sequence diagrams the same use case diagrams.
3. The two ways to indicate data being returned in a Sequence Diagram are:
i. by a return assignment with the “:=” operator

ii. by a return assignment with the “=>” operator
iii. as a return message using a dashed arrow.
iv. as a return message using a dark arrow.
A. i and ii
B. i and iii
C. ii and iii
D. 1 and iv
4. When a message is sent from an originating object to a destination object, in

programming terms, it means that
A. the destination object is invoking a method on the originating object.

B. the originating object is invoking a method on itself.
C. the originating object is invoking a method on the destination object.
D. All of the above
5. Purpose of data access layer is
A. Principle of data provision.

B. Principle of separation of responsibilities.
C. Provides the link between the internal objects and the external environment.
D. Provides a way to retrieve object

STUDY GUIDE
2. Select a few use cases and draw the Sequence Diagram.
3. Draw the Package Diagram.

STUDY GUIDE
CHAPTER 16: System Operational-1

1. Describe implementation activities

2. Describe various types of software tests (unit, integration, usability, and performance and
stress)
3. Explain how and why each software test is used
16.1 Testing
Testing is part of implementation activities under the core processes.
Figure 16-1: Implementation and deployment

Testing activities are the 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)
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.
There are four types of testing for different phase. During Implementation: Unit Testing and
Integration Testing. During Deployment: System testing and User acceptance testing (UAT)
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.

STUDY GUIDE
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.
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 .
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.
16.2 Test case and data

A test case is a formal description that has a starting state or condition, one or more events to
which the software must respond and The expected response or ending state
Test data is 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 behaviour, such as the display of
certain information, or a specific state of stored data, such as a cancelled order.
16.3 Unit Testing

Unit testing is 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. The 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.
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 test of a component often depends on others unit, either to receive a parameter or to
output a result. For example: blue is the unit to be tested, green is the input or output units.

STUDY GUIDE
Figure 16-2: Unit test

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.
Figure 16-3: Unit test with Driver and Stub

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.”

STUDY GUIDE
16.4 Integration Testing

Integration testing is to test the interfaces between these units and to test the entire integrated
piece of software. It evaluates the functional behaviour of a group of classes or components
when they are combined together.
Two types of results that can be tested: test the interface itself between the components and
Integration testing activities.
16.4.1 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.
16.4.2 Integration testing activities

Building the component for integration test: write driver and stub for integration testing and
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.
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.
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.

STUDY GUIDE
16.5 System testing

System test is a comprehensive integration test of the behaviour of an entire system or
independent subsystem. It is performed at the end of each iteration where software is
completed. It is to verify the functional and non-functional requirements; Business functions,
Response time, Stability, Resources usage, Throughput and Speed.
The types of System test are Build and smoke and Performance test (stress test).
Performance test includes Response time and Throughput
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”).
Build and smoke test provides 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.
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.
Performance tests are complex because they can involve multiple programs, subsystems,
computer systems, and network infrastructure. It require a large suite of test data to simulate
system operation under normal or maximum load.
16.5 User Acceptance Testing (UAT)

User acceptance test (UAT) is comprehensive system testing to determine whether the system
fulfils user requirements and can support all business and user scenarios. It is 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.
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.
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.
STUDY GUIDE
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 non-functional requirements. .
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 fulfilment of the specification.
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?”
Figure 16-4: Simple UAT test case list

UAT test data includes 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
Management and Execution of the UAT decide who will participate and who has
responsibility for the UAT. Ideally system users have primary responsibility. Should 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.
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)
STUDY GUIDE
Figure 16-5: Test case tracking list

Essential Reading

STUDY GUIDE
1. What are the tests that is done during implementation?

i. Unit Testing
ii. Integration Testing
iii. System testing
iv. User acceptance testing (UAT)
A. i and ii
B. ii and iii
C. i and iv
D. iii and iv
2. What are the tests that is done during deployment?
i. Unit Testing
ii. Integration Testing
iii. System testing
iv. User acceptance testing (UAT)
A. i and ii
B. ii and iii
C. i and iv
D. iii and iv
3. Which type of test is to ensure that software components must perform to the defined
requirements and specifications in isolation.
A. Unit Testing
B. Integration Testing
C. System testing
D. User acceptance testing (UAT)
4. Which type of test is to ensure that software components perform correctly when
executed in combination with other components.
A. Unit Testing
C. System testing

STUDY GUIDE
5. Which type of test is to ensure that software satisfy the business need and meet all user
“ease of use” and “completeness” requirements.
A. Unit Testing
C. System testing
Write the Unit Test code for ShoppingCart class.
Unit Test the following methods:
- addOrder
- getOrders
- placeOrder
- getPendingOrders
- clearAllOrdersHistory
Assume you are the Manager of the Bubble Tea shop and you are tasked to do the UAT for
Bubble Tea Client.
Write the test cases to perform the UAT.
Sample template UAT document for tester

No Cross Steps to Input Data Expected Actual Result
reference perform Output Output (Pass/Fail)
to use
case

STUDY GUIDE

1. Describe the deployment activities

2. List various approaches to data conversion and system deployment
3. Discuss the advantages and disadvantages of the approaches
4. Describe training and user support requirements for new and operational systems
17.1 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.
The main activities are
• UAT
• Converting and Initializing Data
• Training Users
• Configuring the Production Environment
Figure 17-1: Deployment activities


STUDY GUIDE
17.2 Converting and Initializing Data

Converting and Initializing Data is 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.
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
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.
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.

STUDY GUIDE
17.3 Training Users

Training Users is an essential part of any system deployment project. There two types of
users; end users and system operators.
End users are people who use the system from day to day to achieve the system’s business
purpose. System operators are people who perform administrative functions and routine
maintenance to keep the system operating.
Documentation and other training materials are 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 and User
documentation. System documentation has descriptions of system requirements, architecture,
and construction details. User documentation has descriptions of how to interact with and use
the system
System Documentation provides information to developers and other technical personnel who
will maintain and upgrade the system. It is 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
User Documentation provides ongoing support for end users of the system. It 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

STUDY GUIDE
17.4 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.
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.
The diagram shows a typical support infrastructure for an application deployed using
Microsoft .NET, a variant of SOAP.
Application software components written in such programming languages as Visual Basic

and C# are stored on one or more application servers. 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).
Figure 17-2: Configuring the Production Environment


STUDY GUIDE
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.
Essential Reading

STUDY GUIDE
1. Which of the following is not an activity in deployment?

A. Converting and Initializing Data
B. Training Users
C. Unit Testing
D. Configuring the Production Environment
2. Data needed at system start-up can be obtained from which source(s)?
A. Files or databases of a system being replaced

B. Manual records
C. Files or databases from other systems in the organization
D. All of the above
3. Descriptions of how to interact with and use the system is written in which
documentation?
A. User documentation
B. System documentation
C. Use case documentation
D. Interaction documentation
4. Descriptions of system requirements, architecture, and construction details is written in

which documentation?
A. User documentation
B. System documentation
C. Use case documentation
D. Interaction documentation
5. Which of the following statement with regard to Configuring the Production Environment
is false?
A. Modern applications are built from software components based on proprietary
standards
B. Modern applications are built from software components based on same standards
C. Modern applications are built from software components based on .Net standards
D. Modern applications are built from software components based on Java EE standards

STUDY GUIDE
1. Produce the user guide for the end user.
2. Include screen capture in the user guide.

STUDY GUIDE

1. Explain the difference types of deployment (direct, parallel, and phased)
18.1 Deployment Activities

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.
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 information system operations
• Training personnel and familiarizing customers with new procedures
Different approaches to deployment represent different trade-offs among cost, complexity,

and risk. The most used deployment approaches are:
• Direct deployment
• Parallel deployment
• Phased deployment
18.2 Direct Deployment

In direct deployment or 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.
Figure 18-1: Direct deployment


STUDY GUIDE
The advantages are simplicity and old and new systems aren’t operated in parallel, fewer
logistical issues to manage and fewer resources required. The disadvantage is risk, older
systems aren’t operated in parallel, no backup if the new system fails.
18.3 Parallel Deployment

In parallel deployment, the 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.
Figure 18-2: Parallel deployment

The advantage is relatively low operational risk. Any failure in the new system can be
mitigated by relying on the old system. The disadvantage is cost, during the period of parallel
operation, the organization pays to operate both systems. Full parallel operation may be
impractical, for example new and old system are using the same hardware.
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.
18.4 Phased deployment

In 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.

STUDY GUIDE
Figure 18-3: 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
The advantage is reduced risk because failure of a single phase is less problematic than
failure of an entire system. The disadvantages are 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
Essential Reading

STUDY GUIDE
1. Which of the deployment installed the new system and quickly made operational, and any
overlapping systems are then turned off?
A. Direct deployment
B. Parallel deployment
C. Phased deployment
D. All of the above
2. Which of the deployment, the old and new systems are operated for an extended period of
time (typically weeks or months)?
D. All of the above
3. Which of the deployment, the system is deployed in a series of steps or phases. Each
phase adds components or functions to the operational system.
D. All of the above
4. Which of the deployment is the highest cost and most complex?
D. All of the above
5. Which of the deployment is the simplest?
D. All of the above

STUDY GUIDE
1. How to reduce risk for direct deployment?
2. What are the extra costs associated with operating two systems in parallel?
3. Write the deployment plan for the Bubble Tea ordering system.
• User app to order bubble tea in store
• System process the order
• App for the barista to view order, process order and inform the user to collect
the bubble tea.
• User app to order bubble tea in store at home, assume using third party
delivery service GrabFood.
• Manager website for data analytics
• User app for membership (e.g. points and reward system)
Assume there are a 5 stores outlet for deployment.

STUDY GUIDE
CHAPTER 19: Current Trends in System

Development-1
1. Describe the elements of the Unified Process (UP)

2. Compare and contrast the features of Extreme Programming and Scrum
Development
19.1 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. They are only
proposing 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) 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.
19.1.1 The Unified Process

The Unified Process is an object-oriented system development methodology. It defines a
complete methodology that uses UML for system models and describes a new, adaptive
system development life cycle. It is based on an iterative approach, each iteration is like a
mini-project. The 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 UP divides a project into four major phases, each phases has a different focus.
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase
Figure 19-1: The Unified Process

STUDY GUIDE
UP Phases
Each phase describes the emphasis or objectives of the project team members and their
activities at that point in time. It provides 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.
Inception
Inception phase develops an approximate vision of the system, make the business case, define
the scope, produce rough estimates for cost and schedule and usually completed in one
iteration
Elaboration Phase
In 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 and produce realistic estimates for cost and schedule
Elaboration Phase
To 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. It usually
involves several iterations
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.
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.

STUDY GUIDE
19.1.2 Unified Process Disciplines

Unified process disciplines is to be used within each iteration. It is a set of functionally
related activities that contributes to one aspect of the development project. It includes
business modelling, requirements, design, implementation, testing, deployment, configuration
and change management, project management, and environment. Each iteration usually
involves activities from all disciplines.
Each iteration, typically last four weeks and size of the shaded area under the curve for each
discipline indicates the relative amount of work included from each discipline during the
iteration
Figure 19-2: Unified Process Disciplines

UP Disciplines are divided into two main categories: system development activities and
project management activities. The system development activities are business modelling,
requirements, design, implementation, testing and deployment. The project management
activities are configuration and change management, project management, and environment.

STUDY GUIDE
19.1.3 UP Phase and Disciplines

All nine UP disciplines are employed throughout the lifetime of a project but to different
degrees.
In 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). 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 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 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).
In 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).
In construction phase, most of the use cases have been designed and implemented in their
initial form. It focuses 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.
19.1.4 UP Disciplines
The project management activities includes Configuration and change management and
Project management
Configuration and change management involve setting up processes to support the coding
activities. It includes guidelines as when and how to release code as well as when and how to
manage releases and versions.
Project management includes planning the iterations, assigning work, and verifying that work
has been completed. The Environment involves those tasks required to establish the working
environment, tools to be used by the team and guidelines about how to work together in an
iterative Agile project.

STUDY GUIDE
Unified Process should always be tailored to the project,tailored to the development team and
the specific project. The 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.
19.2 Extreme Programming (XP)

Extreme programming is an adaptive Agile development methodology. It attempts 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
Figure 19-3: XP core values and practices

Extreme programming core values includes communication, simplicity, feedback, and

courage
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.
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.

STUDY GUIDE
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.”
Figure 19-4: XP Practices

XP Practices: Planning
It 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.
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). Zit heavily involve the users in the project rather than have them to
simply sign off on specifications.
XP Practices: Testing
Tests for each story be written first—before the solution is programmed. There are 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, and the users write the acceptance tests.
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.

STUDY GUIDE
XP Practices: Pair Programming

It 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.
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.
XP Practices: Simple Designs

It is done continually in small chunks. The 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.
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 and produces high-quality, robust code.
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.
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.
XP Practices: On-Site Customer

It requires 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.

STUDY GUIDE
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?”
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.
XP Practices: Forty-Hour Week and Coding Standards

This set the tone for how the developers should work. The exact number of hours a developer
works isn’t the issue. The 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.
19.3 Scrum
In Rugby game, a scrum, is to get a ball back into play after a penalty. It begins quickly, very
intense effort, involves the entire team, and usually only lasts for a short duration. The
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.
Figure 19-5: An overview of the Scrum approach

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
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.

STUDY GUIDE
Only a few of the high-priority items are worked on at a time, according to the current needs
of the project.
Product owner is the client, with additional responsibilities. He 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.
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 master is comparable to a project manager. He enforces Scrum practices and helps the
team complete its work. Any hindrance so the team can do its work. Thefocal point for
communication and progress reporting. He doesn’t set the schedule or assign tasks, The team
does. He protects the team from any intrusions.
Scrum team is 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 team sets its own goal for what it can accomplish in a specific period of time. The
team 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. 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 Practices mechanics consists of how a project should progresses. The basic work
process is called a sprint, all other practices are focused on supporting a sprint. A Scrum
sprint is a firm period called a time box, with a specific goal or deliverable.
Beginning of a sprint is when 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. 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 planning meeting is conducted every day by the Scrum master. He holds a meeting
with all members of the team. The objective is to report progress and is limited to 15 minutes
or some other short time period. Members of the team answer only three questions:

STUDY GUIDE
• 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?
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.
Essential Reading

STUDY GUIDE
1. Which unified process phase is to develop an approximate vision of the system, make the
business case, and define the scope?
A. Inception Phase
B. Elaboration Phase
C. Construction Phase
D. Transition Phase
2. Which unified process phase is to identify and describe all requirements, finalize the
scope, design implement the core architecture and functions and produce realistic
estimates for cost and schedule?
A. Inception Phase
D. Transition Phase
3. Which unified process phase is to iteratively implement the remaining lower-risk,

predictable, and easier elements and prepare for deployment?
A. Inception Phase
D. Transition Phase
4. Which unified process phase involve the final user acceptance and beta tests, and the
system is made ready for operation?
A. Inception Phase
D. Transition Phase
5. The practice "Forty-Hour Week and Coding Standards" is advocated in which software
development methodology?
A. Unified Process
B. Extreme Programming
C. Scrum
D. All of the above

STUDY GUIDE
1. Describe an information system project that might have three subsystems. Discuss how
Unified Process and three iterations might be used for the project planning?
2. What is the product backlog used for in a Scrum project?
3. Explain how a Scrum sprint works.
4. Scrum planning meeting has the following characteristics

• 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?
If you are the Project manager, how would you modify the above to suit your needs?
Explain the rational for those modifications.

STUDY GUIDE
CHAPTER 20: Current Trends in System

Development-2
1. Discuss the trends in technology infrastructure

2. Discuss the trends in application platform
20.1 Gartner Top 10 Trends Impacting Infrastructure &

Operations for 2020
Note: the following content is adapted from
https://www.gartner.com/smarterwithgartner/gartner-top-10-trends-impacting-
infrastructure-operations-for-2020/
As the trends for every year changes, do go to Gartner website to get the latest trends.
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
Trend 2: Hybrid IT vs. disaster recovery confidence

Hybrid IT combines on-site data centres with cloud technologies. Hybrid IT blends cloud
architecture flavours—public, private, hybrid—with in-house data centres 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. 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 centres and at the edge.
Trend 3: Scaling DevOps agility

An increasing number of enterprise product teams work in DevOps environments.
DevOp is a set of practices that combines software development (Dev) and IT
operations (Ops). It aims to shorten the systems development life cycle and
provide continuous delivery with high software quality. It complementary with Agile
software development; several DevOps aspects came from the Agile methodology.
(https://en.wikipedia.org/wiki/DevOps)
Ensure the skills needed are available at scale and that many teams do not end up duplicating
effort in similar ways.

STUDY GUIDE
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 centre 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.
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.”
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.
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.
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.
Trend 9: Networking — what’s next?

Automation will be key for enabling networks that are simpler, more reliable and responsive
to change. Starlink is a good example. (https://www.starlink.com/)
Starlink is 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.
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.

STUDY GUIDE
Essential Reading
• Gartner Top 10 Trends Impacting Infrastructure & Operations for 2020.
https://www.gartner.com/smarterwithgartner/gartner-top-10-trends-impacting-
infrastructure-operations-for-2020/
Research on deloitte Insights:
• https://www2.deloitte.com/content/dam/Deloitte/pt/Documents/tech-
trends/TechTrends2020.pdf
Present one of the topic that interest you.


DIT SDT Study Guide

Uploaded by

Copyright:

Available Formats

DIT SDT Study Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DIT SDT Study Guide

Uploaded by

Copyright:

Available Formats

SINGAPORE INSTITUTE OF

Diploma in Information Technology

System Development Techniques

System Copyright by SIM GE, 2021 1

Study Guide Developer : Aaron Yeo Sze Wee

Production : SIM Global Education

Study Guide © SIM Global Education 2021

First Version @ September 2021

System Copyright by SIM GE, 2021 2

System Copyright by SIM GE, 2021 5

System Copyright by SIM GE, 2021 6

The aims of this module are to:

3. Perform analysis of computer-based information systems and present a system description

4. Demonstrate and appreciation of CASE tools such as an aid to systems modelling.

System Copyright by SIM GE, 2021 7

On completion of this module, a student will be able to:

1. Show knowledge and understanding of:

2. Demonstrate module specific skills with respect to:

3. Show cognitive skills pertaining to:

4. Demonstrate transferable skills in:

System Copyright by SIM GE, 2021 8

System Copyright by SIM GE, 2021 9

System Copyright by SIM GE, 2021 10

Supplementary Pressman, R., & Maxim, B. (2015). Software Engineering: A Practitioner’s

Sommerville, I. (2015). Software Engineering (10th ed.). Pearson Education.

Robert, M. C. (2013). Agile Software Development, Principles, Patterns, and

Specific for this module are the following requirements:

System Copyright by SIM GE, 2021 11

1. Discuss the software development and systems analysis and design

1.1 System analysis

1.2 Systems design

System Copyright by SIM GE, 2021 12

1.3 Systems analysis and design

1.4 The System Development Life Cycle (SDLC)

System Copyright by SIM GE, 2021 13

1.5 Agile Development

Agile development philosophy:

Agile development is an approach to system development in which the system is “grown” in

Figure 1-1: Six Core Procsses

System Copyright by SIM GE, 2021 14

System Copyright by SIM GE, 2021 15

1. The main objective of system analysis activities is

A. decides on the software component required in the new information system

2. The main objective of system design activities is

A. to fully understand what the new information system should achieve.

A. System maintenance is a mandatory part of SDLC.

4. Which of the following is not part of Agile development philosophy?

A. the plan must be strictly followed and cannot be changed

5. Which of the following is not a benefit of Agile development?

System Copyright by SIM GE, 2021 16

2. What is the difference between systems analysis and systems design?

Group in a team of four or five persons.

System Copyright by SIM GE, 2021 17

Sample System Vision Document:

System Copyright by SIM GE, 2021 18

CHAPTER 2: SYSTEMS REQUIREMENTS

1. Discuss the systems requirements

2.1 System analysis

The activities are as follows:

Figure 2-1: Analysis Activities