System Analysis & Design

Chapter One: Systems Planning and

Selection

1
 Informationsystems analysis and
design is a step by step complex
method where by computer based
Information systems that can
perform basic business function are
developed and maintained.

2
 Application software (Information System) to
improve employee efficiency.
• From the definition it is to understand that
„System‟, specifically „information system‟ is a core
concept

3
 The word System is derived from Greek word
Systema
 A system is an interrelated set components
used within an identifiable boundary, working
together for some purpose (to achieve a
common goal).

4
A system has nine characteristics
1. Components: is either an irreducible part or aggregate parts, also called
a subsystem
2. Interrelated components: the function of one is somehow tied to the
functions of the others
3. Boundary: the limits of a system with in which the system is contained,
and that separates it from other systems.
4. Purpose: the components work together to achieve some overall purpose
for the larger system: the system‟s reason for existing.
5. Environment: everything outside the system‟s boundary that influences
the system.
6. Interfaces: the points at which the system meets its environment. An
interface also occurs between subsystems.
7. Constraints: the limits to the system (in terms of capacity, speed, or
capabilities)
8. Input: what the system takes in from the environment in order to
function
9. Output: the result of the function of the system.
5
Participants in Information System Development
 Normally system development is team work and project based.

 Who do you think are the stakeholders (participants) in IS design and

development?
 How does each of these stakeholders participate?
 System owners- pay for the system to be built and maintained. They own the
system, set priorities for the system and determine policies for its use. In some
cases, system owners may also be system users.
 System users- are the people who actually use the system to perform or
support the work to be completed. System user defines the business
requirements and performance expectations for the system to be built.
 System analysts- facilitate the development of information system and
computer applications by bridging the communication gap that exists between
non technical system owners and users and technical system designer
and builder.
 System designers- are the technical specialists who design the system to
meet users‟ requirements. In many cases, system designers may also be
system builder.
 System builders – are the technical specialist who construct, test and
deliver the system in to operation.
 IT vendors and consultants- who sell hardware, software and services to
businesses for incorporation into their information system. 6
This diagram shows as six phases of SDLC
Project Identification and
Selection

Project Initiation and

Planning

Analysis

Design

Implementation

Maintenance

7
 This is the first stage where the need for a
new or enhanced system is identified.
 This need may arise as a result of:
oProblem faced by users in day to day
operations or their desire to perform additional
tasks (by end users)
oFrom the realization that IS could be used to
capitalize an opportunity as a result of
organization‟s strategic planning process( by
system analysts)
oA need for efficiency and effectiveness ( by
the management)

8
 This phase involves a preliminary investigation
of the system problem or opportunity at hand
and the presentation of reasons why the system
should or should not be developed by the
organization.
 This phase specifically involves such tasks:
•Assessing feasibility of the IS development project
◦ Types of Feasibility Analysis
1.Economic Feasibility
2.Technical Feasibility
3.Operational Feasibility
4.Schedule Feasibility
5.Legal Feasibility
6.Political Feasibility
•Listing the activities involved
•Preparing a (time) schedule of the activities( using tools like PERT
and Gantt charts)

9
 Analysis involves a thorough study of an organization’s
current procedures and the information systems used to
perform tasks.
 Analysis consists the following major tasks:
 Requirement determination- involves gathering facts about
the users actually want through interviews, questionnaires,
observation and so forth.
 Requirement structuring- involves using models or graphical
representations of user‟s requirement or the current system. It
also involves trying to avoid any redundancies in the current
system. The models used can be Data Flow Diagram, Data
dictionaries and so forth.
 Finally we have to prepare initial design alternatives and
choose between them at this stage.
◦ For instance, we have to decide between buying and building in house the
application software for the proposed system

10
 At this stage the physical specification is
turned into a working system, the system is
tested and then put to use.
 This phase specifically involves:
•Coding
•Testing
•Installation
•Data conversion (data entry)
•User training
•Finalizing documentation

12
 A system has to be maintained once it has been
implemented. Maintenance requests may arise as a
result of:
•Faults found in the system user
•Better way of doing a task using the system or
improvements on the system thought out by users
•Change in the nature of business functions on
environment
 Over time it becomes obvious that because of
prohibitive nature the costs spent to maintain a
system it may be necessary to throw it out and
design a new system which takes as back to the
project identification and selection phase.

13
 Fact finding: involves gathering data or feedback
about different aspects
 Documentation and presentation: recording
facts and specifications for a system for current
and future reference and communicating these
findings
 Feasibility analysis: measuring how beneficial
the development of an IS would be to the
organization.
 Project management: defining, planning,
directing, monitoring and controlling a project to
develop an acceptable system within the allotted
time and budget
 Change management: training and convincing
users about the change that is going to happen as
a result of the IS to be developed
14
 Usually separate models are used to structure
the data, logic and process aspects of the
proposed system (remember this is a
structured system analysis and design
course). Accordingly we have three different
modeling:
1.Processmodeling
2.Logic modeling
3.Data modeling


15
 Process modeling involves graphically
representing the functions, or processes which
capture, manipulate, store and distribute data
between a system and its environment and
between components within a system
 One common process modeling tool is data flow
diagram which you will learn in this lesson

16
Process
 All information systems include process
 These processes respond to business events and conditions and
transform data into useful information
 In process modeling the whole system is viewed as a process
 A process is work performed on incoming data flows or conditions
 In the simples view of a system the system is a process taking in inputs
and giving out outputs
 The system is inside a boundary; the environment is outside that
boundary
 The system exchanges inputs and outputs with its environment
 A diagram can be built (using DFDs) that shows the system as a single
process taking in inputs from its environment and giving out output to its
environment. Such a diagram is called a context diagram (or if DFDs
are used it is called a context data flow diagram)

17
 A complex system is usually very difficult to fully understand when
viewed as a whole (as a single process as represented on a context
diagram)
 Thus, in systems analysis we break a system down into its component
subsystems which are further broken down into smaller subsystems until
we have identified manageable subsets of the overall system. This process
is called decomposition
 One diagram that helps analysts to break down a system (process) down
into its components is called decomposition diagram
 In a decomposition diagram each process is either a parent process, a
child process or both
 A process is usually composed of and decomposed down to functions,
events and elementary processes or primitive processes
1

Process

18
Data Flows
 Processes respond to inputs and generate outputs
 Thus, at a minimum, all processes have at least one input and
one output data flow
 Data flows are the communications between processes and the
system‟s environment
 A data flow represents:
 An input of data to a process

 An output of data from a process, or

 The creation, deletion, reading, or updating or data in a file or

database (a data store)

Data Flow

19
External Agents (source or sink)
 All information systems respond to events and conditions in the system‟s
environment
 The environment of an information system includes external agents that form
the boundary of the system and define places where the system interfaces
with its environment
 External agents are external to the system being analyzed or designed
 In practice, an external agent may actually be outside of the business (such
as government agencies, customers and suppliers) or it may be inside the
organization but outside the scope of the system being analyzed (such as
other department or other internal information systems)
 External agents should be named with descriptive singular nouns such as
REGISTERAR, SUPPLIER, FINANCIAL INFORMATION SYSTEM and so forth.
To avoid crossing data flow lines on a DFD, you can repeat external agents
on the DFD.
 Just remember to put external agents on the perimeters of the page to show
that external agents are the boundary of the system

External Agent/
(Source/sink)

20
Data Stores
 Most information systems capture data for later use
 The data is kept in a data store. Ideally, essential data stores describe the
“things” about which the business wants to store data.
 These things include:
 Persons (group of persons) such as customer, department division employer,
instructor and so forth
 Places such as region, center, building, branch office and so forth

 Objects such as book, machine, part, product, raw material, tool and so forth

 Events such as application, award, class, flight, order, invoice and so forth

 Concepts such as account, course, fund and so forth

 Generally data stores should be named as plurals of the data entities identified.
The naming should avoid any physical terms such as file, database, file cabinet
and so forth

21
A. Context Diagram
 Is a data flow diagram (DFD) of the scope of an organizational system that
shows the system boundaries, external entities that interact with the system
and the major information flows between the entities and the system
 Contains no data stores

B. Level – O Diagram
 A data flow diagram (DFD) that represents system‟s major processes, data
flows and data stores at higher level of detail
 Show the major subsystems and their interactions
 Containing better details than context
 Contains processes exploding from context diagram
 The major processes are subjectively decided by the analysts
 General guideline for selecting major processes
 A process that maintains the inflow and /or outflow of a data store
 Process directly responsible for the production and/or distribution of data to
Source/sink (external entity)
 Process that directly captures data from one or more source/sink
 If the process is a high level descriptor process

C. Level-n Diagram
 A higher level decomposition of each process in the immediate (n-1) DFD level

22
 MoE

Application Placed Student list

Applicants University
Management report manager
O
Colleges Student Grade Student list
Registrar Colleges
system
Diploma & Trans.
Graduates Request
Graduates

Statistical Report
MoE

23
 DFDs don not show the logic inside the process
 Before logic modeling it is important to have process specification
 Process specification are small portion of the total system and they
are created for the primitive processes of the DFDs
Used to explain the decision making logic and formulas that will
transform input data into output
Basically includes items like number, name, description, input data
flow, output data flow, and actual process logic in structured
English, decision table, or decision tree form
Example of process specification
 Number
 Name : determine quantity available
 Description : determine if an item is available for sale
 Input data flow: =>> Valid data item from process 1.2
=>> Quantity on hand form items record
 Output data flow : Available item (Item No + Quantity sold) to
processes 1.4 and 1.5
 Process logic: If --- then---
Else ---

24
 Focuses on the logic of the decisions, steps, choice, etc that are
made, or need to be made, within the organization to carry out
the objectives of the business
 DFDs do not show the logic inside the process (function) thus
logic modeling involves representing internal structure and
functionality of processes depicted on a DFD
 As we use DFD in process modeling, we also have the following
most common techniques in logic modeling (decision analysis)
1. Structured English (pseudo code)

2. Decision tables

3. Decision trees

4. Sequence diagrams

5. Activity diagrams

 Accordingly, the deliverables and outcomes of such modeling are

the results of these techniques (diagrams, tables, etc)
25
 Appropriate technique to use when the process logic involves formulas or iterations or when the decision are not
complex (simple)
 It is a modified form of English and has no standard version
 Any analyst can use his/her dialect of English, by using verbs, i.e names of processes (to describe processes) and noun
phrases to describe data structures. And no usage of adjectives or adverbs
 It can be used to represent the 3 basic types of programming logic:
i. Sequence with no special order (structure) flow
E.g BEGIN
Process 1. Step 1
Step 2
Process 2. Step x
Step y
…
END
ii. Conditional: - with conditions using If…Else.
iii. Repetition: - with some repetitions based on condition, using Do…Until etc
Convention in writing structured English
 Express all logic in terms of sequential, conditional or iterations
 Use and capitalize accepted key words like IF, THEN, ELSE, DO etc
 Follow indentations to show hierarchy
 Underline words or terms used in data dictionary to signify that they have a specialized reserved meaning.
E.g IF flight exist THEN
IF seat is available THEN
Reserve is ok
ELSE
Waiting list
ELSE
26
There is no flight source to destination
 A matrix representations of the logic
 It specifies the possible conditions and the resulting actions
 Best used for complicated decision logic
 Consists of 3 parts
 Condition stubs: list of conditions relevant to decision
 Action stubs: list of actions that result from a given set of conditions
 Rules: links conditions to actions and specify which actions to be followed for a given set of conditions.
Standard procedure to construct decision tables
 Name the condition and values each condition can assume
 Name all possible actions that can occur
 List all rules
 Define the actions for each rule
 Simplify the table (by removing unnecessary rules)
 Consult users
Example: - Company X has two types of employee‟s salaried and hourly workers. For salaried workers, the company pays
monthly. For hourly workers, it pays based on the number of hours worked. If the hourly workers works more than 40
hours, the person paid the normal payment (hours*rate) plus bonus. If hours worked is 40 hours only normal
payment is given. However, if the hours worked is less than 40, absence report will be generated in addition to the
payment. Decision table for payroll system
Conditions
Employee type: S=Salaried, H=Hourly
Numbers of hours worked: <40, =40, >40
Actions
Pay basic salary
Pay wage + Bonus
Wage
Absence report
27
 Conditions/course of Rules
Condition actions 1 2 3 4 5 6
stubs
Employee Type S H S H S H
Hours worked <40 <40 40 40 >40 >40
Pay basic salary X X X
Action Wages plus bonus X
stubs Wage X X
Produce absence report X

Note: you can simplify (reduce) decision tables if there are indifferent
conditions, i.e. a conditions whose value does not affect which actions
are taken for two or more rules; in the above case , hours worked is an
indifferent conditions for rules 1,3,5. Accordingly, the reduced form of
the above table is as follows.
Conditions/course of actions Rules
1 2 3 4
Employee Type S H H H
Hours worked - <40 40 >40
Pay basic salary X
Wages plus bonus X
Wage X X
Produce absence report X

28
 A graphical representation of a decision situation
 Decision situation points are connected by arcs and terminate
in ovals
 It has two main components
Decision points: represented by nodes
Actions: represented by ovals
How to do
 It is read from left to right
 Each node has a number corresponding to a numbered choice
on a legend
 All possible actions are listed on the far right
 Identify all conditions and actions and their order and timing
 Begin building the tree from left to right while making sure
you are complete in listing all possible alternatives before
moving over to the right.

29
Example: - Decision tree representation of the decision logic in the
decision table we have seen before

Yes Pay Basic Salary

1
No
Yes
2 Pay Wages + Bonus

No
Yes Pay wages

3
No
Legend
Pay wage & generate
1. Salaried? absence

2Hours worked > 40?

3Hours worked = 40?

Note: you may find different types of notations other the one here for
decision trees in different books.
30
 So far the topics covered were about:
 Flow of data between different steps
 The decision logic of processing data
 Data modeling deals about the natural
structure of the data at rest (in data store)
 It is a technique for organizing and
documenting (representation) of a system‟s
(organizational) data
 Its purpose is to show rules about the meaning
and interrelationships among data
 Entity–Relationship (E-R) diagramming is
the most common format used for data
modeling
31
 First step is to develop a data model for the
system being replaced
 Next, a new conceptual data model is built that
includes all the requirements of the new system
 In the design stage of the project, the
conceptual data model is translated in to
physical design
Deliverables and outcome
 E-R diagrams

32
 E-R modeling notations use three main constructs
1. Data entities

2. Relationships

3. Attributes

 E-R diagram is a detailed logical representation of the entities, associations

and data elements for an organization or business.

FIGURE Sample conceptual data model diagrams: (A) Standard E-R notation.

33
Entity
 A person, place, object, event or concept in the user
environment about which the organization wishes to
maintain data
 Represented by a rectangle in E-R diagrams, with entity
name in the rectangle with capital letters STUDENT
Example
 Person: EMPLOYEE, STUDENT, PATIENT, etc
 Place: STORE, STATE, WAREHOUSE, etc
 Object: MACHINE, BUILDING, PRODUCT, etc
 Event: SALE, REGISTRATION, RENEWAL, etc
 Concept: ACCOUNT, COURSE, WORK CENTER, etc
There is a difference between entity type and entity instance
 Entity type (entity class): a collection of entities that
share common properties or characteristics. It is named
as singular noun.
 Entity instance: a single occurrence of an entity type
34
 Entity --> Student

Student Id S. Name F. Name

1244 Ahmed Oumer

Instances 1245 Macy Bill

1246 Moges Lemma

35
Attributes
 A property or characteristics of an entity that
is of interest to the organization
 We use an initial capital letter, followed by
lowercase
 We use an ellipse shape to represent attributes
in E-R diagrams and a line connects it to the
associated entity. Its name is replaced in the
ellipse.
Example of attributes:
STUDENT: Student_ID, Student_Name,
Home_Address, Phone_Number, Major

36
Candidate keys and identifiers (primary keys)
 Candidate key is an attribute (or combination of attributes) that uniquely
identifies each instance of an entity type.
E.g. A candidate key of STUDENT entity type may be Student_Id
A candidate key of EMPLOYEE type may be Employee_Id or
Combination of Employee_Id and Address (assuming that no two employees
with the same name live at the same address)
Identifier (also called primary key) is a candidate key that has been selected
to be used as the unique characteristics for an entity type.
 For each entity, the name of the identifies is underlined on E-R diagram
Multi Valued Attributes
 A multi valued attribute may take on more than one value for each entity
instance
Example
 An employee entity with multi valued attributes called skill, if each employee
can have more than one skill.
Two ways of showing multi valued attributes on E-R diagrams
1. Double-lined ellipse
2. Separate the repeating data (the multi valued attribute) into another entity
called weak (or attributes) entity, and use a relationship line to link the weak
entity to its associated regular entity.
37
Relationships
 A relationship is an association between the instances of one or more
entity type that is of interest to the organization
 An association means that event has occurred or that there exists some
natural linkage between entity instances
 Relationships are labeled with verb phrases, and they may be shown in E-R
diagrams using diamond symbols (as shown below) or simply place the
relationship name near the line.
Completes

 Two verb phrases may be used, for an explicit name of the relationship in
each direction.
Example: A company‟s training department is interested in tracking which
training course each of its employees has completed. This leads to a
relationship (called completes) between the employee and course entity a
type that is diagrammed as follows:

Employee Course
Completes

 As indicated above by the arrows this is a many to many relationship.

Each employee may complete more than one course and each course may be
completed by more than one employee.

38
Degree of a relationship
 It is about the number of entity types that participate in that relationship
 The three most common relationships:
1. Unary (degree one)

2. Binary (degree two)

3. Ternary (degree three)

FIGURE Examples of the three most common relationships in E-R diagrams: unary,
binary, and ternary

39
Cardinalities in Relationship
 Suppose two entity types A and B are connected by
a relationship; the cardinality of a relationship is
the number of instances of entity B that can (or
must) be associated with each instance of entity A.

MOVIE VIDEOTAPE
Is_stocked_as

 Here, a video shop may stock more than one

videotape of a given movie. This is an example of a
“many” relationship.

40
Minimum and Maximum Cardinalities
 The minimum cardinality of a relationship is the number of
instances of entity B that may be associated with each instance of
entity A.
 In the above example, the minimum number of video tapes available
for a movie is zero, in which case we say that VIDEOTAPE is an
optional participant in the relationship, when the minimum
cardinality of a relationship is one, we say entity B is a mandatory
participant in the relationship.

MOVIE VIDEOTAPE
Is_stocked_as

 The zero near videotape means a minimum

cardinality of zero, while the crow‟s foot notation
means a “many” cardinality.

41
1. Mandatory cardinalities

PATIENT PATIENTHISTORY
Has

 Patient has patient history

 Each patient has at least one or more patient
histories
 Each instance of patient history “belongs” to one
patient

42
2. One optional, one mandatory cardinality
EMPLOYEE PROJECT
Is_assigned_to

 Each project has at least one assigned employee

(some projects have more than one)
 Each employee may or (optionally) may not be
assigned to any existing project, or may be
assigned to several projects

43
3. Optional cardinalities

PERSON
Is_married_to

 This is an optional 0 or 1 cardinality in both

directions, since a person may or may not be married
 It is possible for the maximum cardinality to be a
fixed number, not an arbitrary “many” value. These
all depend on the business rule or policy of the
organization

44
Associative Entities
Date_Completed Associated relationship

Employee Course
Completes

 Here, date-completed is neither the property of EMPLOYEE,

nor of COURSE. Instead, it is the property of the
relationship between two entity types. The attribute is
associated with the relationship and diagramed as shown
above.
 Since many-to-many and one-to-one relationship may have
associated attributes a decision should be made whether
that is an entity or a relationship and it depends simply on
how view the data.
 An associative entity (also called gerund) is a relationship
that the data modem chooses to model as an entity type.
45
 After analyzing the existing system, determining the
new user requirement and how data, process and
logic should be modeled in the new system, the next
step is to select the best way of designing the system
 Design strategy is a high level statement about the
approach to developing an information system
 It includes statements of the system‟s functionality,
hardware and system software platforms, and
method of acquisition
There are two sub activities
1.Generating alternative design strategy

2.Selecting the appropriate strategy

46
The Design Strategies
1. Custom development (build from scratch)
 Custom development is developing the system in house from scratch.
This requires the organization to have its own IT professional capable of
developing a system
Allows flexibility and creativity

Problems are best explained and identified by employees

Builds technical skills and functional knowledge in-house

Requires significant time and effort

May exacerbate existing Backlogs

May require missing skills

Often costs more

Often takes more calendar time

Problems may be overlooked

Risk of project failure

47
2. Purchase and customize
 There are various software already on shelf that could be used for
information management.
 This software could be purchased off-the-shelf from vendor software
suppliers and customized to fit a specific organizational need.
Rarely a perfect fit with business needs

May allow for customization

oManipulation of system parameters

oChanging May allow for customization

oChanging way features work

oSynchronizing with other application interfaces

Building systems by combining packages, legacy system, and custom

pieces
Integrating data is the key

Common criteria to select the best software to buy could be: cost,
functionality, vendor support, flexibility, viability of vendor,
documentation, response time, ease of installation and maintenance.
48
3. Outsource development
 The concept of outsourcing is to analyze the
requirement and forward the need of the users and the
organization to external vendors to design the
system.
 All or some responsibilities of the system development
is turned over to outside firm.
 Hiring an external vendor, developer, or service
provider
 Specialized knowledge exploitation/Domain knowledge
 May reduce costs or add value
 Risks include possibly
Losing confidential information
Losing control over future development
Losing learning opportunity

49
Outsourcing Guidelines
Keep lines of communication open
Define and stabilize requirements before
signing the contract
View the relationship as a partnership
Select vendor, developer, or provide carefully
Assign someone to manage the relationship
Don‟t outsource what you don‟t understand
Emphasize flexible requirements

50
 System Analysis & Design
Chapter Two: System Design

51
 Information system design involves tasks focusing on the
specification of detailed computer based solution: also called
physical design to differentiate from data modeling, which
is basically a logical design
 System analysis emphasized the business-problem while
the system design focuses on the technical or
implementation concerns of the new system
 System design transform results of analysis to certain design
model accordingly:
Input to
DFD Architectural Design

Input to
E-R/data model Database Design
System
Requirement Input to
Specification (SRS) Interface Design (input/output)

52
Deliverables or outputs of system design:
 Architectural design
 Database design and
 Interface design
 Architectural Design: representation of the architecture of a software
system
o The common tool used here is system structure chart (SSC) which is
hierarchical diagram that shows how an information system‟s organized
o It is basically transformation of DFDs into a more procedural way
 Database Design: transformation of E-R diagrams and data requirement
from interface of reports and the like into data i.e. structure the data in
stable structure, called normalized table/relation
 Having minimal redundancy
 Not likely to change over time
o The data objects and relationships defined in E-R diagram and detailed
data content depicted in the data dictionary provide the basis for the
database design activity.
 Interface Design: refers to the concept of designing how the software
communicates within itself (with systems that interoperate with it) and with
humans who use it. An interface implies flow of information and a specific
type of behavior.

53
Database Design: database and file design
occurs in two steps
1.Developing logical database model
2.Physical database design

54
 As mentioned above, database design is transforming an
E-R model and their specifications design into a
normalized relation
 A relation is a named, two _ two _ dimensional tables of
data, having set of named columns and an arbitrary
number of unmade rows
 Each column in a relation corresponds to an attribute of
that relation and each row of a relation corresponds to a
record that contains data values for an entity
 Well structured relation corresponds to records that
contain a minimum amount of redundancy and allows
users to insert, modify and delete the rows without
errors or inconsistencies
 It is the process of converting complex data in to simple,
stable and structures using a process called
normalization

55
 Normalization: is a process of organizing the data in
database to avoid:-
◦ data redundancy
◦ insertion anomaly
◦ update anomaly &
◦ deletion anomaly
 Normalization: performed based on well accepted
principles and rules, there are three steps of
normalization
Un normalized Normalized Relations Second Normal Third Normal Form relations
Relations (1st Normal Form) Form relations (2nd NF) (3rd NF)

 The result of normalizations is that every no primary

key attribute depends upon the whole primary key and
nothing but the primary
 Normalization is based on the analysis of functional
dependence
56
Functional dependence and primary keys
 Functional dependency is particular relationship
between two attributes, in a given relation;
attribute of B is functionally dependent on
attribute A if, for every valid value of A, that value
of A uniquely determine the value of B.
 Example you can express the structure of
relation, by the following shorthand EMPLOTEE
(Emp_ID, Name, Dept, Salary)

57
 EMPLOYEE1 (with sample data)
Emp_ID Name Dept Salary

100 Margaret Simpson Marketing 42,000

140 Allen Beeton Accounting 39,000

110 Chris Lucero Inform. Systems 41,500

190 Lorenzo Davis Finance 38,000

 The functional dependence of B on A is represented by

an arrow as: A B (e.g. Emp_ID Name:- for a given
Emp_ID value, there can be only one Name values
associated with it)

58
 Consider the following relation (EMPLOYEE2) that contains data about
employees and the courses they have completed.

EMPLOYEE2

Emp_ID Name Dept Salary Course Date_Completed

100 Margaret Simpson Marketing 42,000 SPSS 6/19/2002
100 Margaret Simpson Marketing 42,000 Surveys 10/7/2002
110 Chris Lucero Inf. Systems 41,500 SPSS 1/22/2002
110 Chris Lucero Finance 41,500 C++ 4/22/2002
190 Lorenzo Davis Finance 38,000 Investment 5/7/2002
150 Susan M. Marketing 38,500 SPSS 6/19/2002
150 Susan M. Marketing 38,500 TQM 8/12/2002

 Notice: the redundancy in EMPLOYEE2, where Emp_ID, Name, Dept, and

Salary values for employees 100,110 and 150 appear in we must record this
fact in two rows.
 The problem with this relation is that it contains data about two entities:
EMPLOYEE and COURSE

59
 In normalization, we divide EMPLOYEE2 into relations,
EMPLOYEE1 (above) and the following EMP COURSE relation
having a primary key combining Emp_ID and course.
 EMPCOURSE
Emp_ID Course Date_Completed
100 SPSS 6/19/2002
100 Surveys 10/7/2002
110 SPSS 1/22/2002
110 C++ 4/22/2002
190 Investment 5/7/2002
150 SPSS 6/19/2002
150 TQM 8/12/2002

 An attribute may be functionally dependent on two (or more)

attributes, rather than on a single attribute.
 Example: Emp_ID, courseDate_Completed. In this case,
Date_Completed cannot be determined by either Emp_ID or course
alone, because the Date_Completed is characteristic of an employee
taking a course.

60
To get 1st normal form:
Remove all repeating groups
Identify primary keys
i.e. breaking or dividing the relation into two or more (like the case from
EMPLOYEE2 to EMPLOYEE1 and EMPCOURSE)
Second Normal Form (2NF)
A relation is 2NF if every no primary key attribute is functionally dependent

on the whole primary key, i.e. not on part, but on fullest of the primary key
 Remove partial dependencies to get 2NF relation
A 2NF is satisfied if any one of the following conditions apply
1. The primary key consists of only one attribute
2. No non primary key attribute exist in the relation
3. Every non primary key attribute is functionally dependent on the full set of
primary key attributes
Third Normal Form (3NF)
 A relation is in 3NF if it is in 2NF and there are no functional
dependencies between two (or more) non primary key attributes (a
functional dependency between non primary key attributes is also called a
transitive dependency)
 Consider the following TREATMENT Relation
61
 Treatment

Patient_ID Patient_Name Physician Ward

1570 Anderson Hicks ICU
1575 Simith Faulb IPD
1460 Arnold Hicks ICU
1589 John Mark Medical
1560 Mike Faulb DPD

 Treatment is its 2NF because it has only one primary key attribute
 The following relational dependencies exist in the above relation
1. Patient_ID, Patient_Name, Physician, Ward (Patient_ID is the primary key)
2. Physician ward (each physician is assigned to a unique ward)  transitive
dependency
 A relation like the above create data maintenance problems and need to be changed in
3NF
 To change TREATEMENT relation in into 3NF, decompose it into two relations based on
Patient_ID and Physician as:
TREATMENT (Patient_ID, Patient_Name, Physician)
PHYSICIAN (Physcian, Ward)
 Physician is a foreign key in the treatment relation
 A foreign key is an attribute that appears as a non primary key attribute in one relation
and as a primary key attribute (or part of a primary key) in other relation.
 Sometimes, you may not need to go through all the steps of normalization, a relation
may already be in the 3NF at the 1st step.
62
 The tasks we saw so far are activities of logical
database design
 Physical database design involves the following
activities
Designing fields of tables: choosing data types,
set calculated (or computed or derived) fields,
setting default values, range controls, etc
Designing physical tables in the database
 Activities here take into account the technology
required in processing, accessing etc.

63
 A good human computer interface provide a
unifying structure for finding, viewing and
invoking the different components of a system
 Interface design is basically
• User focused activity
• Employs (user) prototyping methodology
 Interface may be designed to allow
• Command based interactions
• Menu based interaction
• Object-based interaction: icon, symbols
• Natural language interaction

64
Form and Report
 System inputs and outputs- forms and reports- were identified
during requirement structuring.
 A form is a business document containing some predefined data
and often includes some areas where additional data are to be
filled in. Most forms have a stylized format and are usually not
in a simple rows and columns format.
◦ Usually a form is based on one table of a database and
provides some mechanism of interaction with the user.
 On the other hand, a report is a business document containing
only predefined data; it is a passive document used solely for
reading or viewing.
◦ Examples of reports are invoices, weekly sales summaries by
region and salesperson, and a pie chart of population by age
categories. Usually a report contains data from multiple tables
in a database.

65
66
 System Analysis & Design
Chapter Three: Systems Implementation and
Maintenance

67
 System Implementation is the construction, installation and testing
of system components and the delivery of the system for day-to-day
operation
 System implementation involves six major activities. These are:
1. Coding: turning the physical design specifications created at the
design stage into working computer code by programmers
2. Testing: conducting various tests to ensure that the information
system delivers what is expected of it
3. Installation: the process during which the current system is
replaced by the new system. This includes conversion of existing
data, software, and documentation and work procedures to
those consistent with the new system
4. Documentation: finalizing system documentation and preparing
user manual
5. Training: providing training to users on general and specific topics
before they start to use the information system
6. User Support: providing such activities as helpdesk support,
online help and bulletin boards once the information system has
become integrated into the organization

68
1. Coding
 It is the process of converting the physical design specifications created at
the design phase stage into working computer code by programmers
 Here what is important is programming language selection and coding
style
2. System Testing
 There are various types of testing mechanism based on various approaches.
You have to distinguish between:
 Static and dynamic testing- in static testing the code is not executed
whereas dynamic testing involves execution of the code
 Automated and manual testing: this depends on whether the testing is
done by computer or people
 Based on the above distinction there are seven types of testing approaches
outlined in the table below and each is discussed next
Manual Automated

Static Inspections Syntax Checking

Dynamic Walkthroughs Unit test

Desk checking Integration test

System test
69
I. Inspections- are formal group activities where participants
manually examine code for occurrences of well-known errors.
Syntax, grammar and some other routine errors can be checked
by automated inspection software, so manual inspection checks
are used for more subtle errors. Exactly what the code does is
not investigated in an inspection.
II.Syntax Checking- syntax checking is also a procedure
performed to identify know errors in the code but it is different
from inspection because it is done by the computer itself.
III.Walkthroughs- are tests where not only the known errors but
also what the code does is checked walkthroughs are usually
done frequently for pieces of coding done before the final
program is formally tested.
IV.Desk checking- also involves checking the program does what
it is expected to do by an independent, this time around the
whole program is sequentially checked from one module to
another by manually comparing the outputs of the program
with what is expected of it.

70
V. Unit testing- is an automated test method where each module of
the program is tested alone in an attempt to discover any errors that
may exist in module‟s code.
VI. Integration testing- is a process of testing the modules of the
program by incrementally integrating them to see how each module
coexists and works with the other.
VII. System testing- refers to the testing of the information system as
a whole (as a complete entity). System testing involves checking such
things as whether operators have adequate documentation, whether
procedure manuals are clear, determining if output of the system is
correct or not and so forth.
 All the above procedure test whether the system meets its intended
objectives or not (whether it “works” or not).
 As such usually non-live-data are used for the test purpose. Non-
live data are data developed specifically for testing purpose.

71
 There is also testing that will be done by users
themselves in real working environment. Such system
testing is referred to as acceptance testing.
 Acceptance testing is testing done by users using
real data over an extended time period in real
environment. Acceptance testing involves:
I. Alpha testing (verification testing): where the
system is run in a simulated environment using
simulated data. The purpose of alpha testing is to
check for errors and omissions regarding end-user
and design specifications that were specified in earlier
phase of the SDLC.

72
 Beta testing (validation testing)- where the system is run in a live
environment using real data.
 During validation or beta testing the following are checked.
a) System performance- such questions as “is the throughput and
response time for processing adequate to meet a normal processing
workload?”
b) Peak workload processing performance (stress testing) - can the
system handle workload during peak processing periods?
c) Human engineering test- is the system as easy to learn and use
as anticipated?
d) Methods and procedure test- during conversion, the methods and
procedures for the new system will be put to their first real test.
Methods and procedures may have to be modified if they prove to
be awkward and inefficient from the end-users‟ standpoint.
e) Backup and recovery testing- includes simulating data loss
disaster and testing the time required to recover from that disaster.
In addition, a before-and-after comparison of the data should be
performed to ensure that data was properly recovered.

73
3. System conversion (installation)
 The process of moving from the current
information system to the new one is called
system conversion or installation.
 A detailed conversion plan needs to be prepared
before the new system is put into operation.
 Types of System Conversion (Installation)
1. Abrupt cut-over (direct installation)
2. Parallel conversion (installation)
3. Location (pilot) conversion
4. Phased (staged) conversion

74
 In an abrupt cut-over the old system is terminated on
specific date and the new system is placed into
operation.
 This is a high-risk approach as there may still be
major problems that won‟t be uncovered until the
system has been in operation for at least one business
period. On the other hand, there are no transition costs
in a direct installation

75
 In parallel conversion both the old and new system operated for some
time period
 This ensures that all major problems in the new system have been solved
before the old system is discarded
 All of the work done by the old system is concurrently performed by the
new system and the outputs are compared by check if the new system is
performing well
 This strategy minimizes the risk of major problems in the new system
causing irreparable damage to the business
 On the other hand, this approach can be costly as the two system need to
be operated over some period and some costs must be incurred for that.
Usually, this approach is used when the old system is largely manual

76
 When the same system will be used in numerous geographical locations, it is usually
converted at one location first. As soon as the site has approved system, it can be
deployed in the rest of the organization possibly continuing installation in one location
at a time
Advantages:
 Limits potential damage and potential cost by limiting the effects to a single site

 Success at the pilot site can be used to convince reluctant personnel in other sites that
the system can be worthwhile for them as well
 IS staff can devote all their effort at the pilot site to make the system a success

Disadvantages:
 If the different locations require sharing data, extra programs will need to be written
synchronize the current and the new system
 Some parts of the organization will not get the benefits of the new system until the pilot
installation has been completely tested

77
 The phased conversion is an incremental approach where the new system is brought
on-line in functional components; different parts of the old and the new system are used
in cooperation until the whole new system is installed.
Advantages:
 Risk and cost are spread out over a period of time

 Allows for some benefits from the new system even before the whole system is ready.

 Each phase of change is small and manageable for users and IS staff

Disadvantages:
 Bridge programs connecting old and new databases and programs often must be built.

 A phased installation is like bringing out a sequence of repeated conversions at each

phase and a long period of change which may be frustrated and confusing users.

78
 Each information system developed results in various documents
of its own.
 The contents of the final documentation may vary from
organization to organization and from the SDLC followed.
 However, the following can be reasonably expected to be included
in any system documentation.
 System requirement specification  Test reports

 Resource requirements specification  User‟s guide

 Management plan  Release description

 Engineering change proposal  System administrators guide

 Architecture design document  Reference guide

 Prototype design document  Acceptance sign-off

 Detailed design document

 Test specification

79
In general, documentation can be divided into two
types:
1. System documentation which records detailed
information about a system‟s design specification,
its internal workings, and its functionality. System
documentation is primarily intended for
maintenance programmers and can be:
Internal documentation: that is part of the
program source code or is generated at program
compile time
External documentation: that includes the
outcome of all of the structured diagramming
techniques such as DFDs. External documentation
can be maintained and updated using CASE tool.
80
2. User documentation- consists of written or
other visual information about an application
system, how it works and how to use it.

81
Training topics
 The type of necessary training will vary by type of system and
expertise of users.
Training methods
 Every user learns best under various methods depending on
his/her personalities and background. Some users learn best by
seeing, others by hearing and still others by doing. Because it is
not usually possible to customize training for every individual a
combination of methods is often the best way to follow.
Training users
Who to train
 All people who will have primary or secondary use of the new
information system must be trained..
People who train users
 For a large information systems project may different trainers
may be used depending on how many users must be trained and
who they are:
82
 User support is an ongoing technical support
provided to users.
 Regardless of how well the users have been
trained and how good the end-user
documentation is, users will eventually require
additional assistance because unanticipated
situations may arise or new users are added.

83
The system maintenance process
 The maintenance process phase is the last phase in
the SDLC and makes the SDLC a lifecycle.
 That is when an information system needs to be
maintained the steps taken almost look like the
whole SDLC.
 They include:
 Obtaining maintenance request
 Analysis of the request to understand its scope and
how it will affect the current system
 Designing changes
 Implementing changes

84
 System Analysis & Design
Chapter Four: Understanding the Basics: Object
Oriented Concepts

85
 The concepts of objects and classes are intrinsically linked with
each other and form the foundation of object oriented paradigm.
Object
 A person, thing, place, event, concept, screen or report that are
relevant to the system being analyzed
E.g. Gemechu, Tesfaye, OOSAD etc…
 Object has attributes that describe it. Attribute define the data.

E.g color, weight, height, size, serial number etc…

 Object also has relationships with other objects.

E.g. Car object related to its Owner

 Object has function that it can do. Methods define the function.

E.g. Register, change color, change owner

 Object is a representation of real world class.

 This makes it an abstraction of the real world.

 Objects are something physical or conceptual.

 Objects are instances of Class.

86
Class
 In the context of object oriented systems, a class is a
collection of things sharing a common attributes.
 Is a group of objects with similar properties/ similar

attributes but also common behaviors /operations,

common associations to other objects & they have
common semantics.
 Classes are used to distinguish one type of object

from another.
 An individual object is an instance of a class.
E.g. Gemechu and Tesfaye are student objects but we model the
class as a student.

87
E.g. STUDENT --> Class

Name Id. No. Year DOB

Gemechu NSR/01/12 1st 1967 -->Object

Tesfaye NSR/02/12 1st 1984

Class = Table+ Functions

Object = Record + Functions

88
 Classes are modeled in one of two ways.
 Either a rectangle that list attributes & methods or as a
rectangle.
Class Name
(STUDENT)
Class Name
Attributes Or (STUDENT)
Methods

Remarks
 Class names are nouns. Single noun or a combination
of nouns.
 Class names are singular
E.g. STUDENT
STUDENTS are not class name
89
Attributes
 Equivalent to data element in a record.
 Attribute is something a class or objects knows.
 And it is a single piece of data or information.

STUDENT
Name, Stud ID, DOB <-- Attributes

RegisterCourse, DropCourse <-- Methods

90
Methods
 A function or procedure.
 Method is something a class or object does & it

modifies & access attributes of a class or object.

 Some methods return a value/ like a function

where as other methods don‟t like a procedure.

91
 The world is a complicated place.
 To deal with that complexity we form abstractions of the things in it. For

example, consider the abstraction of a person.

◦ From the point of view of a university, it needs to know the person's
name, address, telephone number, social security number, and
educational background.
◦ From the point of view of the police, they need to know a person's
name, address, phone number, weight, height, hair color, eye color,
finger print and so on. It is still the same person, just a different
abstraction, depending on the application at hand.
 Abstraction is an analysis issue that deals with what a class knows or

does. Your abstraction should include the responsibilities, the attributes,

and the methods of interest to your application and ignore the rest. That
is why the abstraction of a student would include the person's name and
address, but probably not his or her height and weight.
 OO systems abstract only what they need to solve the problem at hand.

92
 Encapsulation is the process of binding both attributes and
methods together within a class.
 In the object-oriented world, you modularize systems into

classes, which, in turn, are modularized into methods and

attributes.
System-->Class -->Attributes & Methods
 Encapsulation is an Object Oriented Programming concept that
binds together the data and functions that manipulate the data.
 Encapsulation is a design issue that deals with how
functionality is compartmentalized within a system.

93
 Information hiding is a process of hiding or the secret of an
object that do not contribute to its essential characteristics.
 By restricting access to attributes you prevent programmers from
writing highly coupled code.
 To make your applications maintainable, you want to restrict
access to data attributes and some methods.
 The basic idea is this: if one class wants information about
another class, it should have to ask for it, instead of taking it.
 When you think about it, this is exactly the way the real world
works. If you want to learn somebody's name, what would you do?
Would you ask the person for his name, or would you steal his
wallet and look at his ID?
 When code is highly coupled, a change in one part of the code
forces you to make a change in another, and then another, and so
on.

94
 We establish relationships between two classes
for one of two reasons.
◦ First, a class relationship might indicate
some kind of sharing.
◦ Second, a class relationship might indicate
some kind of semantic connection.
 There are three basic kinds of class
relationships. They are
1.Inheritance (Generalization)
2.Association
3.Aggregation

95
 Inheritance is a mechanism for expressing similarity
between things thus simplifying their definition.
 Inheritance is a representation of an "is a", "is kind of",

and "is like" relationships between two classes, enabling

you to reuse existing data and code easily.
 It promotes reuse by enabling a subclass to benefit

automatically from all the behavior it inherits from its

super class/classes/.

96
 Once you have the class Person defined, you then
make Student and Professor inherit from it.
 You would say Person is the superclass of both Student
and Professor, and Student and Professor are the
subclasses of Person.
 Everything that a superclass knows or does, the
subclass knows or does free without writing extra code.
o Actually, for this example, you would need to write
two lines of code, one saying Student is a subclass of
Person, and another saying Professor is a subclass of
Person; therefore, it is almost free.
o Because Person has a name, address, and telephone
number, both Student and Professor also have those
attributes.
o Because Person has the ability to drive a vehicle, so do the
classes Student and Professor.
97
Inheritance Tips and Techniques
1.Look for similarities
 For the inheritance to happen the class
should have similar attributes & methods.
2. Look for existing classes
3. Follow the sentence rule
 “Is a”, “Is Like”, “Is kind of”
4. Inherit everything (pure inheritance)

98
Single inheritance
◦ When a class inherited directly from one class.
Multiple inheritance
◦ When a class directly inherited from more than
one class

99
 Generalization and specialization represent a hierarchy of relationships between classes,
where subclasses inherit from super-classes.
Generalization
 In the generalization process, the common characteristics of classes are combined to
form a class in a higher level of hierarchy,
i.e., subclasses are combined to form a generalized super-class.
 It represents an “is a kind of” relationship.
◦ For example, “car is a kind of land vehicle”, or “ship is a kind of water
vehicle”.
Specialization
 Specialization is the reverse process of generalization. Here, the distinguishing features
of groups of objects are used to form specialized classes from existing classes. It can be said
that the subclasses are the specialized versions of the super-class.
 The following figure shows an example of generalization and specialization

100
 Associations are relationships between classes, which help us to
define how they interact with each other.
 Associations are defined by using verbs.

E.g. Student takes Course

 Associations identifies cardinality /How many?/& optionality /Do

we need to have it?/ relationships.

 The UML combines these two (2) into a single concept of multiplicity.

 Multiplicity: a set of integers indicating the number of links that

can legitimately originate from an instance of the class connected to the

association end.

 Roles: a string each end of an association which clarify the purpose of the
association.
 label is optional. The label is one or two words describing the association.

101
102
1. Unidirectional: that may be traversed
in only one direction
E.g. Employee holds position

 A position may be held by an employee

 A position is held by zero or one employee

103
2. Recursive: in which case the objects
involved in it are instances of the same class.
E.g. People marry People

◦ An employee may be managed by another employee

◦ An employee may manage more than one employee

104
3. Bidirectional: this relationship may be
traversed in both direction.
E.g. Student takes Seminar

105
 Aggregation is a special kind of association,
representing a structural relationship between a
whole and its parts.
 Aggregation is the representation of “is part of”

association.
E.g.

 A PoliceStation is composed of PoliceOfficers.

 Directory that contains a number of Files.
106
Aggregation tips and techniques
1.Apply the sentence rule
2.It should be a part in the real world.
E.g. a car engine is not a part of
airplane.
3.You should be interested in the part.
4.Show multiplicity & role.
5.Aggregation is inherited.

107
 Focus on how to save, retrieve and delete
objects to/from permanent storage.
 To make an object persistence you must save
the value of its attributes and any information
needed to maintain the relationship with which it
is involved to permanent storage.
From the development point of view object is
divided in to two:
1. Persistent object: object that stay to the life
time of secondary storage device.
2. Transitors object: object that do not save on
permanent storage device.

108
Tips and Techniques for persistence
1.Business/Domain classes are usually
persistence.
2.User interface (UI) classes are usually
transitory.
3.You need to store both attributes &
associations.

109
 Is a measure of how much two items, such as
classes or methods, are interrelated.
 When one class depends on another class, we
say they are coupled.
 When one class interacts with other class, but
does not know implementation details we say
they are loosely coupled.
 When one class relies on the implementation
(that is, it directly access the data attributes of
the other) of another, we say that they are
highly/tightly coupled.

110
If method 1 access the attributes of class2 the
two classes are highly coupled.
Class 1 Class 2

Attribute 1 Attribute 1

Attribute 2 Attribute 2

etc etc
Method 1 Method 2

 To reduce maintenance burden loosely coupled

class is important.
 High coupling leads to higher maintenance cost.

111
Tips & Techniques for coupling
1. Avoid high coupling if you can
2. Document high coupling thoroughly (in detail
fashion).
 The higher the coupling, the better the documentation
has to be.

112
 Cohesion is the degree of relatedness within an
encapsulated unit (such as a component or class).
 A method is highly cohesive if it does one and only one

thing.
 Strong verb/noun combinations are used to indicate high

cohesion for methods.

E.g. getName, printName, enrollStudent, dropStudent
 A highly cohesive class represents one & only one type of

object.
E.g. class professor is highly cohesive as compared to
class employee.
• Try to reduce coupling & increase cohesion.

113
 Polymorphism is the ability to take more than one
form.
 When a class inherits from another class it inherits
both the attributes and methods of that class, so in
the case of the Car class inheriting from
the Vehicle class the Car class inherits the methods
of the Vehicle class, such as accelerate(), decelerate().
 Polymorphism means "multiple forms".
 In OOP these multiple forms refer to multiple forms
of the same method, where the exact same method
name can be used in different classes, or the same
method name can be used in the same class with
slightly different parameters.
114
 Patterns are reusable solutions to common
problems of software.
Types of patterns
1. Analysis patterns
◦ Describe a solution to common analysis or domain
problem
2. Design patterns
◦ Describe a solution to common design problem.
3. Process patterns
◦ A collection of general techniques, actions or tasks
that address a specific software process problem
taking the relevant factor in to account.

115
 System Analysis & Design
Chapter Five: Object Orientation the new
software paradigm

116
 Software development: is dynamic and always
undergoing major change.
 Today a vast number of tools and methodologies
are available for system development.
 System development: refers to all activities that go
into producing information system solution.
 System development activities consist of system
analysis, modelling, design, implementation, testing
and maintenance.
 A software development methodology is series of
processes that, if followed, can lead to the
development of an application.

117
 It is a way to develop software by
building self-contained modules that
can be more easily:
• replaced
• modified
• reused

118
 OO development offers a different model from the
traditional software development approach. This is
based on functions and procedures.
 To develop s/w by building self-contained modules
or objects that can be easily replaced, modified and
reused.
 In OO environment, s/w is a collection of discrete
object that encapsulate their data as well as the
functionality to model real world ―objects.
 Each object has attributes (data) and method
(function).
 Objects grouped in to classes and object are
responsible for itself.
119
 A software process (also known as software
methodology) is a set of related activities
that leads to the production of the software.
 These activities may involve the development
of the software from the scratch, or,
modifying an existing system
Software Process Models
1. The Waterfall Model
2. The Spiral Model
3. Iterative, Incremental Frameworks

120
 The waterfall model prescribes that each stage must
be complete before the next stage can commence
(start).
 One phase is started when the previous phase is
completed.
 Backtracking is strictly forbidden

121
Advantages
1. Simple and easy to manage

2. We can concentrate only on one stage of the lifecycle

3. More applicable/best for small projects. The project is done with

small number of people and complete within few days.
Disadvantages
1. It takes time
2. Risk is pushed forward
 Major problems often emerge at the latter stages of the process-
especially during system integration.
 Ironically, the cost to rectify errors increase exponentially as time
progresses.
3. Technical requirement changes cannot be easily integrated
4. The process will begin to break down as the complexity of the
system increase.

122
 In this approach, we attack the project in a
series of short lifecycles, each one ending with
a release of executable software
 Here, the project has been divided into different
phases, each phase building on the previous
one and with a running release of software
produced at the end of each phase

123
Advantages
1. The development team will work on all the stages
◦ The team are able to work on the entire lifecycle (Analysis, Design, Code,
Test) rather than spending years on a single activity
2. Early feedback can be obtained
◦ We can receive early and regular feedback from the customer, and spot
potential problems before going too far with development
3. Risks can easily be solved
◦ We can attack risks up-front. Particularly risky iterations (for example, an
iteration requiring the implementation of new and untested technology) can
be developed first
4. The scale and complexity of work can be discovered earlier
5. New requirements and technological change can easily be
integrated
◦ Changes in technology can be incorporated more easily
6. It boosts the morale of the user and developer
 A regular release of software improves morale
8. The status of the project (e.g.- how much of the system is
complete.) can be assessed more accurately
9. Mostly used for complex system

124
Disadvantages
1. It is accompanied by RAD
◦ The process is commonly associated with Rapid
Application Development, so the user must know
RAD to give good feedback.
2. The process is much more difficult to manage
◦ The Waterfall Model fits in closely with classic project
management techniques such as Gantt charts, but
spiral processes require a different approach

125
 The Iterative, Incremental Framework is a
logical extension to the spiral model, but is
more formal and rigorous (difficult)
 It has four phases Inception; Elaboration;
Construction and Transition.
 These phases are performed in sequence, but
the phases must not be confused with the
stages in the waterfall lifecycle.

12
6
A. Inception
 The inception phase is concerned with establishing the
scope of the project and generally defining a vision for
the project.
 For a small project, this phase could be a simple chat
over coffee and an agreement to proceed; on larger
projects, a more thorough inception is necessary.
 Possible deliverables/Artifacts from this phase are:
 A Vision Document
 An initial exploration of the customer‟s requirements
 A first-cut project glossary
 A Business Case (including success criteria and a financial
forecast, estimates of the Return on Investment, etc)
 An initial risk assessment
 A project plan

127
B. Elaboration
 The purpose of elaboration is to analyze the
problem, develop the project plan further, and
eliminate the riskier areas of the project.
 By the end of the elaboration phase, we aim to have
a general understanding of the entire project, even
if it is not necessarily a deep understanding (that
comes later, and in small, manageable chunks).
 Possible deliverables/Artifacts from this phase are
• Refined project plan
• Use case model
• The Use Case Model helps us to understand the
customer‟s requirements
• Class diagram
• Class Diagram to explore the major concepts our customer
understands

128
C. Construction
 At the construction phase, we build the product.
 This phase of the project is not carried out in a
linear fashion- rather, the product is built in the
same fashion as the spiral model, by following a
series of iterations.
 Each iteration is our old friend, the simple
waterfall. By keeping each iteration as short as
possible, we aim to avoid the nasty problems
associated with waterfalls.
 At the end of as many iterations as possible, we will
aim to have a running system (albeit, of course, a
very limited system in the early stages). These
iterations are called Increments, hence the name of
the framework

129
D. Transition
 The final phase is concerned with moving the final
product across to the customers.
 Typical activities in this phase include:
• Beta-releases for testing by the user
community
• Factory testing, or running the product in
parallel with the legacy system that the product
is replacing
• Data take on (i.e. converting existing databases
across to new formats, importing data, etc.)
• Training the new users
• Marketing, Distribution and Sales

130
Structured system analysis and Object oriented system analysis and
design design

1. Data flow methodology 1. Object modeling

2. Complements the structured 2. Compliments object oriented

programming programming
3. Can repeatable, measurable and
3. Can repeatable, measurable and
automated. (ROSE, VISIO, EdrawMax
automated (CASE tools)
&Argo UML tools )
4. Functional perspective of
4. Object perspective of problem domain
problem domain
5. Describe the real world as data
5. Describes the real worlds by its objects,
flowing through IS, being
attributes, services and relationships
transformed from inputs to outputs.
6. Separates data from its 6.. Data and functionalities encapsulated
functionality together

13
1
1. Increased reusability
2. Increased extensibility
3. Improved quality
4. Increased chance of project success
5. Reduced maintenance burden
6. Managed complexity
7. Financial benefits (allow the above
advantages contribute to financial benefits)

132
1. Object oriented requires greater concentration on requirements,
analysis and design.
2. Developers must work closely with users. In this case users is highly
involved in the development project.
3. Object oriented requires a complete change in mindset on the part of
individuals & organization.
4. Object oriented demands upfront investment in training, educations
and tools
5. Many Object oriented benefits are long term
6. Object oriented techniques do not guarantee you will build the right
system
7. Object oriented necessities increased testing
8. Object oriented is more than just programming
9. Object oriented is part of the solution
10. Object oriented requires the development culture of your IS department
to change
13
3
 System Analysis & Design
Chapter Six: Gathering user requirements

134
 A requirement is a feature that the system
must have or a constraint that it must
satisfy to be accepted by the client.
 Requirements engineering aims at defining
the requirements of the system under
construction.
 Requirements engineering includes two main
activities;
• Requirements elicitation, which results in the
specification (description) of the system that the client
understands, and
• Analysis, which results into an analysis model that the
developers can unambiguously interpret.

135
 Requirements elicitation is about
communication among developers, clients,
and users for defining a new system.

136
 Requirements elicitation focuses on describing the purpose of
the system.
 The client, the developers, and the users identify a problem area
and define a system that addresses the problem.
 Such a definition is called a system specification and serves as
a contract between the client and the developers.
 The system specification is structured and formalized during
analysis.
 Both system specification and analysis model represent the
same information.
 They differ only in the language and notation they use.
 The system specification is written in natural language,
whereas the analysis model is usually expressed in a formal or
semiformal notation.
◦ The system specification supports the communication with
the client and users.
◦ The analysis model supports the communication among
developers.
137
What is a stakeholder?
 A stakeholder is someone who has a justifiable claim
to be allowed to influence the requirements.
 Users are nearly always stakeholders.
 Other stakeholders may include:
◦ People whose lives are affected by the system, such
as clients and suppliers
◦ Managers who are concerned for the system to
succeed, although they do not use it as such;
◦ Regulators such as local and state governments
and standards bodies, which are concerned about
the effects the system may have in its
environment.

138
Techniques for capturing requirements include:
• Interviewing users and other stakeholders
• Holding workshops
• Observing users at work
• Searching likely documents, & seeing the changes
that users have made to existing systems.
• Problem reports and suggestions from existing
systems can be valuable sources of requirements,
provided you find out and record how important
each proposed requirement is to its users.

139
• Functional requirements
• Nonfunctional and
• pseudo requirements

140
 Describe the interactions between the system and its environment
independent of its implementation.
 The environment includes the user and any other external system with
which the system interacts.
 Example, the following is an example of functional requirements for
SatWatch, a watch that resets itself without user intervention:

 The above functional requirements only focus on the possible interactions

between SatWatch and its external world (i.e., the watch owner, GPS, and
WebifyWatch). The above description does not focus on any of the
implementation details (e.g., processor, language, display technology)

141
Nonfunctional requirements: describe user-visible aspects of the
system that are not directly related with the functional behavior of the
system.
Nonfunctional requirements include quantitative constraints, such as
response time (i.e., how fast the system reacts to user commands) or
accuracy (i.e., how precise are the system‟s numerical
answers),Performance, User interface, Security, Availability etc..

The following are the nonfunctional requirements for SatWatch:

142
 Pseudo requirements: are requirements
imposed by the client that restricts the
implementation of the system.
 Typical pseudo requirements are the implementation
language and the platform on which the system is to
be implemented.
 The following are the pseudo functional
requirements for SatWatch:

143
 Requirements elicitation activities include:
 Identifying actors
 Identifying scenarios
 Identifying use cases
 Refining use cases
 Identifying relationship among use cases
 Identifying participating objects
 Identifying nonfunctional requirements

144
 Actors represent external entities that interact with the system.
 An actor can be human or an external system.
 The first step of requirements elicitation is the identification of
actors.
 This serves both to define the boundaries of the system and to
find all the perspectives from which the developers need to
consider the system.
 When the system is deployed into an existing organization (such
as a company), most actors usually exist before the system is
developed: they correspond to roles in the organization.
 When identifying actors, you have to ask the following questions:

145
 In the SatWatch example, the watch owner, the GPS
satellites, and the WebifyWatch serial device are
actors.
 They all interact and exchange information with the
SatWatch. Note, however, they all have specific
interactions with the SatWatch.
 Actors define classes of functionality.

146
 A scenario is “a narrative description of what people do and experience as they try
to make use of computer systems and applications”.
 A scenario is a concrete, focused, informal description of a single feature of the system
from the viewpoint of a single actor.
 Below is an example of scenario for the FRIEND system, an information system for
incident response.
 In this scenario, a police officer reports a fire and a Dispatcher initiates the incident
response. Note that this scenario is concrete, in the sense that it describes a single
instance. It does not attempt to describe all possible situations in which a fire
incident is reported.

147
• Developers use existing documents about the
application domain to answer these questions.
• These documents include:-
 user manuals of previous systems
 procedures manuals
 company standards
 user notes and cheat sheets
 user and client interviews.

148
 A scenario is an instance of a use case, that is,
 A use case specifies all possible scenarios for a given piece of
functionality.
 A use case is initiated by an actor.
 After its initiation, a use case may interact with other actors as well.
 A use case represents a complete flow of events through the system
in the sense that it describes a series of related interactions that
result from the initiation of the use case.
 Below is example from the friend system for use case:
ReportEmergency

149
 The use of scenarios and use cases to define
the functionality of the system aims at
creating requirements that are validated by the
user early in the development.
 As the design & implementation of the system
starts, the cost of changing the system
specification and adding new unforeseen
functionality increases.
Note that many use cases are rewritten
several times, others substantially refined,
and yet others completely dropped.

150
 Relationships among actors and use cases enable
the developers and users to reduce the
complexity of the model and increase its
understandability.
• We use communication relationships between
actors and use cases to describe the system in
layers of functionality.
• We use extend relationships to separate
exceptional and common flows of events.
• We use include relationships to reduce
redundancy among use cases.

151
 Communication relationships between actors
and use cases represent the flow of
information during the use case.
 The relationships between actors and use
cases are identified when use cases are
identified.

152
 A use case extends another use case if the extended use case may
include the behavior of the extension under certain conditions.
 Both the extended use case and the extensions are complete use
cases of their own.
 They must have an entry and an end condition and be
understandable by the user as an independent whole.
 In the FRIEND example, assume that the connection between the
FieldOfficer station and the Dispatcher station is broken while the
FieldOfficer is filling the form (e.g., the FieldOfficer‟s car enters a
tunnel). The FieldOfficer station needs to notify the FieldOfficer that
his form was not delivered and what measures he should take. The
ConnectionDown use case is modeled as an extension of
ReportEmergency.

153
 Redundancies among use cases can be factored out
using include relationships.
In the ViewMap use case describes the flow of events
required when viewing the city map and is used by both
the OpenIncident and the AllocateResources use cases

154
Heuristic for extend and include relationships
 Use extends for exceptional, optional or seldom-
occurring behavior
 Use includes for behavior that is shared across two
or more use cases.

155
 Once use cases have been consolidated,
developers identify the participating objects for
each use case.

156
Nonfunctional requirements describe user-
visible aspects of the system that are not
directly related to the functional behavior of
the system.
Nonfunctional requirements span a number of
issues, from user interface look and feel to
response time requirements to security
issues.

157
Nonfunctional requirements can be elicited by investigating the
following issues.
• User interface and human factors. What kind of interface should
the system provide? What is the level of expertise of the users?
• Documentation. What level of document is required? Should only
user documentation be provided? Should there be technical
documentation for maintainers? Should the development process be
documented?
• Hardware considerations. Are there hardware compatibility
requirements? Will the system interact with other hardware
systems?
• Performance characteristics. How responsive should the system
be? How many concurrent users should it support? What is a typical
or extreme load?
• Error handling and extreme conditions. How should the system
handle exceptions? Which exceptions should the system handle?
What is the worse environment in which the system is expected to
perform?
158
• Quality issues. How reliable/available/robust should the
system be? What is the client‟s involvement in assessing the
quality of the system or the development process?
• System modifications. What is the anticipated scope of
future changes? Who will perform the changes?
• Physical environment. Where will the system be deployed?
Are there external factors such as weather conditions that
the system should withstand?
• Security issues. Should the system be protected against
external intrusions or against malicious users? To what
level?
• Resource issues. What are the constraints on the
resources consumed by the system?

159
 System Analysis & Design
Chapter Seven: Ensuring Your Requirements
Are correct: Requirement Validation
Techniques

160
 Requirements are continuously validated with the client and the user.
 Validation is a critical step in the development process, given that both
the client and the developer are dependent on the system specification.
 Requirement validation involves checking if the specification is correct,
complete, consistent, unambiguous, and realistic.
 A specification is correct if it represents the client’s view of the system (i.e.,
everything in the requirements model accurately represents an aspect of the
system).
 It is complete if all possible scenarios through the system are described, including
exceptional behavior (i.e., all aspects of the system are represented in the
requirements model).
 The system specification is consistent if it does not contradict itself.
 The system specification is unambiguous if exactly one system is defined (i.e., it is
not possible to interpret the specification two or more different ways).
 Finally, it is realistic if the system can be implemented within constraints.

161
 Validation (& Verification), is the process of checking
whether the requirements, as identified, do not
contradict the expectations about the system of
various stakeholders and do not contradict each
other.
 It is Requirements Quality Control

162
 Validation: “Am I building the right product?”
checking a work product against higher level work
products or authorities that frame this particular
product.
• Ensures that the software being developed (or changed) will
satisfy its stakeholders.
• Checks the software requirements specification against
stakeholders‟ goals and requirements.
• Requirements validation makes sure that requirements meet
stakeholders‟ goals and don‟t conflict with them.
o Requirements are validated by stakeholders
163
 Verification: “Am I building the product right?”
checking a work product against some standards
and conditions imposed on this type of product and
the process of its development.
 Ensures that each step followed in the process of building the
software yields the right products.
 Checks consistency of the software requirements specification
artifacts and other software development products (design,
implementation ...) against the specification.
o Requirements are verified by the analysts mainly

164
• Simple checks
• Reviews and inspections
• Scenario Test
• Prototype Test
• Product test

165
Simple Checks
 Various checks can be done using traceability
techniques
• Given the requirements document, verify that all
elicitation notes are covered.
• Tracing between different levels of requirements
 Checking goals against tasks, features, requirements…

 Verify that the requirements are well written.

166
Reviews and Inspections
 A group of people read and analyze requirements
• Look for potential problems
• Meet to discuss the problems and
• Agree on a list of action items needed to address these
problems

167
Scenario Test
 During this test, one or more users are presented with a visionary
scenario of the system.
 Developers identify that:
• how quickly users are able to understand the scenario
• how accurately it represents their model of work and
• how positively they react to the description of the new system
 The selected scenarios should be as realistic and detailed as
possible.
 A scenario test allows rapid and frequent feedback from the user.
 The advantage of scenario tests is that they are cheap to realize
and to repeat.
 The disadvantages are that the user cannot interact directly with
the system and that the data are fixed.
168
Prototype Test
 During this type of test, one or more users are presented with
a piece of software that practically implements the system.
• A vertical prototype implements a complete use case
through the system, and
• A horizontal prototype presents an interface for most use
cases (without providing much or any functionality).
 The advantages of prototype tests are that they provide a
realistic view of the system to the user and that prototypes can
be instrumented to collect detailed data.
 The disadvantages of prototypes are that they are expensive to
build and to modify.

169
Product Test
 This test is similar to the prototype test except that a
functional version of the system is used in place of the
prototype.
 A product test can only be conducted once most of the
system is developed.
 It also requires that the system be easily modifiable such
that the results of the usability test can be taken into
account.

170
 The results of the requirements elicitation activity and the
analysis activity are documented in the Requirements
Analysis Document (RAD).
 This document completely describes the system in terms of
functional and nonfunctional requirements and serves as a
contractual basis between the client and the developers.
 The audience for the RAD includes the client, the users, the
project management, the system analysts (i.e., the developers
who participate in the requirements), and the system
designers (i.e., the developers who participate in the system
design).

17
1
172
 System Analysis & Design
Chapter Eight: Determining What to Build:
OO Analysis

173
 The purpose of analysis is to understand what will be built.
 This is similar to requirements gathering, the purpose of
which is to determine what your users want to have built.
 The main difference is that:
 The focus of requirements gathering is on understanding your
users and their potential usage of the system.
 Whereas the focus of analysis shifts to understanding the system
itself.
 The following figure depicts the main artifacts of your analysis
efforts and the relationships between them.
 The solid boxes indicate major analysis artifacts
 Whereas the dashed boxes represent your major requirements
artifacts.
 The arrows represent “drives” relationships; for example, you
see that information contained in your CRC model affects
information in your class model and vice versa.

174
  The following fig. has three important
implications.
1. First, analysis is an iterative process.
2. Second, requirements gathering and analysis are
highly interrelated and iterative.
3. Third, the “essential” models, your essential use
case model and your essential user interface
prototype, evolve into corresponding analysis
artifacts respectively, your use case model and
user interface prototype. What isn‟t as obvious is
that your Class Responsibility Collaborator (CRC)
model evolves into your analysis class model.
175
176
 Use case model describes how your users work
with your system, reflecting the business rules
pertinent to your system, as well as aspects of your
user interface model.
 Sequence diagrams or activity diagrams uses to
flesh out and verify the logic contained in your use
cases.
 Sequence diagrams act as a bridge to your class
model, which depicts the static structure of the
classes from which your system will be built.
 User interface model, including your user
interface prototype and your user interface flow
diagram also drives changes to your class model.

177
 During analysis, your main goal is to evolve your
essential use cases into system use cases.
 The main difference between an essential use case
and a system use case is,
 In the system use case, you include high level
implementation decisions.
What is a system use case model?
 Similar to essential use case models, a system use
case model is composed of :
 A use case diagram and
 The accompanying documentation describing
 The use cases
 Actors and
 Associations

178
Components of Use case Diagram
A. A use case describes a sequence of actions that provide a measurable
value to an actor and is drawn as a horizontal ellipse.

B. An actor is a person, organization, or external system that plays a role in

one or more interactions with your system. Actors are drawn as stick figures.

C. Associations between actors and classes are indicated in use case diagrams,
a relationship exists whenever an actor is involved with an interaction described
by a use case.
 Associations also exist between use cases in system use case models.
 Associations are modeled as lines connecting use cases and actors to one
another, with an optional arrow head on one end of the line indicating the
direction of the initial invocation of the relationship.

179
D. The rectangle around the use cases is called the
system boundary box and, as the name suggests, it
delimits the scope of your system the use cases inside
the rectangle represent the functionality you intend to
implement.

E. Finally, packages are UML constructs that enable

you to organize model elements (such as use cases) into
groups.

 Packages are depicted as file folders that can be used

on any of the UML diagrams, including both use case
diagrams and class diagrams.

180
 Writing system use cases is fairly straightforward.
 You begin with your essential use cases and modify them to
reflect the information captured within UML sequence
diagrams, UML activity diagrams, user interface prototype
and the contents of evolved supplementary specification.
 You will also rework use cases to reflect opportunities for
reuse, applying the UML stereotypes of <<extend>> and
<<include>>, as well as the object oriented concept of
inheritance.
 Use cases can be written in narrative style, the use case is
written in this way where the basic and alternate courses of
action are written one step at a time.
 A second style, called the action response style, presents
use case steps in columns, one column for each actor and a
second column for the system.

181
1. Use case Identification
1. Name: Enroll in Seminar
2. Identifier [optional]: UC 17
2. Use case history [optional]
1. Created by
2. Date created
3. Last updated by
4. Date last updated
3. Description for the use case
1. Description: Enroll an existing student in a seminar for which he is eligible.
4. Actors [optional]
5. Description for the Actor
6. Status [optional]
 Used to show the exact status of the use case (work, failed, success)
7. Frequency
 Used to show how much we use the use case
8. Preconditions
 Used to show what are the conditions that must be satisfied before we use the use case.
1. Preconditions: The Student is registered at the University.
9. Post conditions
 Used to show that will be fulfilled after the use case is completed over.
1. Post conditions: The Student will be enrolled in the course he wants if he is eligible and
room is available.

182
10. Extended use case [optional]
11. Included use case [optional]
12. Assumption [optional]
13. Basic Course of Action or normal course main
path:
1. The student wants to enroll in a seminar.
2. The student inputs his name and student number into
the system via “UI23 Security Login Screen.”
3. The system verifies the student is eligible to enroll in
seminars at the university, according to business rule
“BR129 Determine Eligibility to Enroll.”
4. The system displays “UI32 Seminar Selection
Screen,” which indicates the list of available seminars

183
14. Alternate Course of action
Alternate Course A: The Student is Not Eligible to
Enroll in Seminars
A.3. The system determines the student is not eligible to enroll
in seminars.
A.4. The system informs the student he is not eligible to
enroll.
A.5. The use case ends.
Alternate Course B: The Student Does Not Have the
Prerequisites
B.6. The system determines the student is not eligible to enroll
in the seminar he has chosen.
B.7. The system informs the student he does not have the
prerequisites.
B.8. The system informs the student of the prerequisites he
needs.
B.9. The use case continues at Step 4 in the basic course of
action.
15. Decisions
184
1. Use Case
1.1. Use case names begin with a strong verb
E.g. EnrollinSeminar
1.2 Name use cases using domain terminology
1.3 Place your primary use case in the top left corner of the diagram.
(For readability purpose)
1.4 Apply timing consideration by stacking use cases

185
2. Actors
2.1 Place your primary actors/actor in the top left corner of the diagram ( in the following
figure customer is primary actor)
2.2 Draw actors to the outside of the use case diagram.
o The sum of all use cases gives the scope of the system.
o Actors are not part of our system but they interact directly to the system.
2.3 Name actors with singular business relevant nouns.
o Use domain specific terminology
E.g. in registrar system the actor is student not participant
2.4 Associate each actor with one or more use cases.
o An actor can interact at least one use case & at most the whole use case.
2.5 Actors model roles not positions.
o While try to identify actor you have to identify model not positions.
2.6 Use <<System>> to indicate system actors
2.7 Actors do not interact with one another.
o The only relationship between actors is inheritance (used to simplify use case)
2.8 Introduce an actor called “time” to initiate scheduled event (periodical)

186
3. Relationships
3.1 Indicate an association between actors and use case if the actor
appear with in the use case logic.
3.2 Avoid arrow heads to actor use case relationship.
o It is highly recommended to avoid arrow head
3.3 Apply <<include>> when you know exactly when to invoke the use
case.
3.4 Apply <<extend>> when a use case may be invoked across several use
case steps.
3.5 Avoid more than two levels of use case associations.
o This use case increase complexity, increase functional decomposition & failure of
one use case cause the failure of the others, it increase response time.
3.6 Place an include use case to the right of the invoking use case. The
included use case place on the right of including use case.
3.7 Place extending use case below the parent use case.
3.8 The inheriting use case place below the parent (base) use case.
3.9 Apply the “is like” rule to use case generalization.
3.10 Apply the “is like” rule to actor inheritance.
3.11 Place an inheriting actor below the parent actor.

18
7
4. System boundary boxes
4.1 Indicate release scope with a system
boundary box.
o For implementation order
4.2 Avoid meaningless system boundary boxes

188
Extend Associations between Use Cases
 An extend association, is a generalization relationship where an
extending use case continues the behavior of a base use case.
 The extending use case accomplishes this by conceptually inserting
additional action sequences into the base use case sequence.
 This enables an extending use case to continue the activity sequence
of a base use case when the appropriate extension point is reached in
the base use case and the extension condition is fulfilled.
Include Associations between Use Cases
 An include association, is a generalization relationship denoting the
inclusion of the behavior described by another use case.
 The best way to think of an include association is that it is the
invocation of a use case by another one.
Inheritance
 Use cases can inherit from other use cases, offering a third
opportunity to indicate potential reuse.
 Inheritance between use cases is not as common as either the use of
extend or include associations, but it is still possible.
 The inheriting use case would completely replace one or more of the
courses of action of the inherited use case.
189
190
 Represent the system‟s behavior in terms of
interactions among a set of objects.
 Sequence diagrams are used to model the logic
of usage scenarios.
 A usage scenario is exactly what its name
indicates the description of a potential way your
system is used.
 The logic of a usage scenario may be part of a
use case, perhaps an alternate course.

191
UML sequence diagram are used to:
1. Validate & flesh out the logic of a usage scenario.
 Enables you to visually model the logic of your system and
 The flow of logic with in your system and are commonly used for both
analysis and design.
2. Explore your design
3. It helps to detect bottle necks within an object
oriented design
4. Will give you a feel free for which classes in your
system application are you going to complex.
5. Gives a bridge between use case modeling &
conceptual modeling.
6. A Sequence diagram must draw for each course of
action.
19
2
1. The boxes across the top of the diagram represent
classifiers or their instances; typically use cases objects,
classes, or actors.
• Objects have labels in the standard UML format “name:
ClassName,” where “name” is optional (objects that haven‟t
been given a name on the diagram are called anonymous
objects).
 Classes have labels in the format “ClassName,” and
 Actors have names in Actor Name
2. The dashed lines hanging from the boxes are called object
lifelines, representing the life span of the object during the
scenario being modeled.
3. The long thin boxes on the lifelines are method-
invocation boxes indicating that processing is being
performed by the target object/class to fulfill a message.
19
3
4. The at the bottom of a method-invocation box is a UML
convention to indicate that an object has been removed from
memory, typically the result of receiving a message with the
stereotype of <<destroy>>.
5. Messages are indicated as labeled arrows,
 when the source and target of a message is an object or class

the label is the signature of the method invoked in response to

the message.
 However, if either the source or target is a human actor, then

the message is labeled with brief text describing the information

being communicated.
6. Return values are optionally indicated as using a dashed
arrow with a label indicating the return value.

194
1. Strive from left to right ordering of message.
 A message below one process it will perform after this
process.
2. Layer the classifiers anything that are written above the sequence
diagram can be use case, actors, methods, interfaces.
 Actor -->Controller --->User Interface
3. Name actors consistently with your class diagram.
4. Name classes consistently with your class diagram.
5. An actor can have the same name as a class.
 We have to give stereotype for actor class & we don‟t give
stereotype for business class.
6. Include short description of the logic [optional]
 Increase the readability of the sequence diagram
 Increase the traceability (checking) of the sequence diagram
7. Place human and organization actors on the left most side of your
diagram. (because the actor are highly involved in the system)
8. Avoid modeling object destruction.
195
 Class Diagrams: are used to represent the structure of
a system in terms of:
• Objects
• Their attributes and operation
• Relationships
 Class models are the main stay of object-oriented
analysis and design.
 Class models show:
◦ The classes of the system
◦ Their interrelationships (including inheritance,
aggregation, and association), and
◦ The operations and attributes of the classes.

196
19
7
 Modeled dependencies between user
interface classes and the business
classes with which they collaborate
because user interface classes are
transitory in nature, implying the
associations they are involved with are
transitory and, hence, should be modeled
as dependencies.
 Whenever a collaboration occurred between
two business classes, modeled an
association.
198
1. Identify responsibilities on domain class
diagram.
2. Indicate visibility only on design class diagram

Visibility Symbol Accessible to

1. Public + All objects with in your system

2. Protected # Instances of the implementing class and

its subclasses

3. Private - The implementing class

4. Package ~ Instances of classes within the same

package

19
9
3 . Indicate language dependent visibility with property strings

4. Indicate data types only on design models

 It is recommended to identify at analysis phase
5. Indicate data types on analysis model only when the type is an
actual requirement (the type will never be changed at design
phase)
6. Design class diagram should reflect language naming
conventions
E.g. attributeName
200
7. Model association classes (also called link classes)on
analysis diagram

 Association class is modeled in analysis phase because

the concept of association class is not supported by most
of programming language.
8. Do not name association that have association classes.
For the above E.g. we don‟t give the name of association
between the student & course class because the association
class is by itself is descriptive.
9. Center the dashed line (-----) of an association class.
 For readability purpose 20
1
1. Use common terminologies for names
2. Prefer complete singular nouns for class name
E.g. Customer
 Cust X -we have to give complete name rather than a
shorter name
3. Name operations with stronger verb (because strong verb is more
descriptive) Initial Name Good Analysis Name Good Design Name
Open account openAccount openAccount
Mailing Label Print printMailingLabel printMailingLabel
Purchase parking bus () purchaseParkingBus () purchaseParkingBus ()

Save the object() Save() Save()

4. Name attribute with a domain based noun

E.g. firstName
5. Do not model scaffolding code
 <<getter>> accessor
 <<setter>> mutator
 Instead using getAttributeName(), setAttributeName()

20
2
6. Never show classes with two compartments.
 It is possible more than three compartments of class
7. Label uncommon class compartments
8. Include an ellipsis (…) at the end of incomplete lists.
9. List static operations or attributes before instance
operations or attribute.
10. List operations or attributes in decreasing visibility
1. Public 2. Protected 3. Private
11. Develop consistent methods signature
 Naming operations
 Parameters
 Order of parameters
12. Avoid stereotypes implied by language naming
conventions.
 Avoid this stereotype <<custructor>> <<setter>> instead
setItem(), <<getter>> instead getItem()

20
3
 The bulk of the documentation work is documenting the details about
a class, as well as the reasoning behind any trade-offs you have made.
Here‟s what to do:
1. Classes
 A class is documented by a sentence or two describing its purpose.
 You should also indicate whether the class is persistent or transitory,
and if it has any aliases (other names it is called) for the class.
 Documenting the potential alias for a class is important because
different people in an organization can call the same thing by different
names.
 Also, include references to any applicable business rules or constraints
contained in the supplementary specification.
2. Attributes
 An attribute is best described with one or two sentences
 Its type should be indicated if appropriate
 An example should be given if not unclear how the attribute is to be
used and a range of values should be defined, if appropriate.
 Also, include references to any applicable business rules or constraints
contained in the supplementary specification.
20
4
3. Methods
 Methods are documented with pseudo-code, also known as
structured English, describing its logic.
 The parameters (if any) and the return value (if any) should be
documented in a manner similar to attributes.
 The preconditions and post conditions for the method should be
indicated so developers understand what the method does.
 Also, include references to any applicable business rules or
constraints contained in the supplementary specification.
4. Inheritance. [optional]
5. Associations
 The most important information about associations the label,
multiplicities, and roles already appear on the diagram. I typically
also include a few sentences describing the association,
 As well as reference any applicable business rules or constraints
contained in the supplementary specification.
6. Aggregation and composition
 These are both documented exactly as you would associations.

20
5
 Activity diagram: are flow diagrams used to
represent the data flow or the control flow
through a system.
 UML activity diagrams are used to document
the logic of a single operation/method, a single
use case, or the flow of logic of a business
process.
 In many ways, activity diagrams are the object-
oriented equivalent of flow charts and data-flow
diagrams (DFDs) from structured development.

20
6
1. Starting point: [mandatory] the filled circle represents the starting point of the activity

diagram effectively a placeholder and

2. Ending point: [optional] the filled circle with a border represents the ending point.

3. Activity or activity state/process: the rounded rectangles represent

processes or activities that are performed.

4. Decision Point: the diamond represents decision points.

5. Transition: the arrows represent transitions between activities, modeling the flow

order between the various activities. The text on the arrows represent conditions that must

be fulfilled to proceed along the transition and are always described using the format

“[condition].”

6. Fork, Join the thick bars represent the start and end of potentially parallel
20
activity. 7
 User interface prototyping is an iterative analysis
technique in which users are actively involved in the
mocking up of the UI for a system.
UI prototyping has two purposes:
 First, it is an analysis technique because it enables you to
explore the problem space your system addresses.
 Second, UI prototyping enables you to explore the solution
space of your system, at least from the point-of-view of its
users, and provides a vehicle for you to communicate the
possible UI design(s) of your system.
Steps in the UI prototyping process:
1. Determine the needs of your users
2. Build the prototype
3. Evaluate the prototype
4. Determine if you are finished

20
8
Determining the Needs of Your Users
 User interface modeling moves from requirements definition into
analysis at the point you decide to evolve all or part of your essential
user interface prototype, into a traditional UI prototype.
 This implies that you convert your hand drawings, flip-chart paper,
and sticky notes into something a little more substantial. You begin
this process by making platform decisions.
 For example, do you intend to deploy your system so it runs in an
Internet browser, as an application with a Windows based graphical
user interface (GUI), as a cross-platform Java application, or as a
mainframe based set of “green screens”?
 Different platforms lead to different prototyping tools
 For a browser based application, you need to use an HTML development tool
 Whereas a Java based application would require a Java development tool and
a different approach to the user interface design.
Building the Prototype
 Using a prototyping tool or high-level language, you develop the
screens, pages, and reports needed by your users.
 Major UI elements HTML pages, Screens, Reports.
 Minor UI elements would become buttons, list boxes, custom list boxes, radio
buttons, and so on as appropriate

20
9
Evaluating the Prototype
 After a version of the UI prototype is built, it needs to
be evaluated by your users to verify that it meets their
needs. I‟ve always found I need to address three basic
questions during an evaluation:
 What is good about the UI prototype?
 What is bad about the UI prototype?
 What is missing from the UI prototype?
Determining If You Are Finished
 After evaluating the prototype, you may find you need
to scrap parts of it, modify parts, and even add brand-
new parts.
 You want to stop the UI prototyping process when you
find that the evaluation process is no longer generating
any new ideas or it is generating a small number of not-
so-important ideas. Otherwise, back to step one.

21
0
 Analysis patterns describe solutions to common problems
found in the analysis/business domain of a system.
The Advantages and Disadvantages of Patterns
 Several advantages and disadvantages exist to working with
object oriented patterns.
The Potential Advantages of Patterns
1. Patterns increase developer productivity.
2. Patterns describe proven solutions to common problems.
3. Patterns increase the consistency between applications.
4. Patterns are potentially better than reusable code.
5. More and more patterns are being developed every day.
The Potential Disadvantages of Patterns
1. You need to learn a large number of patterns.
2. The NIH (not-invented-here) syndrome can get in the way.
3. Patterns are not code.
4. “Pattern” is quickly becoming a buzzword (slogan).

21
1
 The user documentation is part of the user interface for
an application and that well written user documentation is
no excuse for a poorly designed user interface.
 My experience confirms these beliefs because modern
systems are complex, your users often require significant
documentation that describes how to use them effectively.
 Because different types of users have different needs, you
also discover you need to develop several kinds of user
documentation.
Types of User Documentation
1. Tutorial manual for novice (beginner) users
2. A user manual for intermediate users
3. Reference manual for expert users
4. Support user‟s guide describing the support services
provided to your user community, a document that is
typically less than a page in length.
21
2
 Packages are UML constructs that enable you to
organize model elements into groups, making your UML
diagrams simpler and easier to understand.
 Packages are depicted as file folders and can be used
on any of the UML diagrams, although they are most
common on use case diagrams and class diagrams
because these models have a tendency to grow.
 Use packages only when diagrams become unwieldy
(Bulky), which generally implies they cannot be printed
on a single page, to organize a large diagram into smaller
ones.
 A good rule of thumb is that a diagram should have 7
+/– 2 bubbles on it, a bubble being a use case or class.

21
3
 System Analysis & Design
Chapter Nine: Determining How to Build Your
System: OO Design

214
 The purpose of design is:
• to determine how you are going to build your system &
• to obtain information needed to drive the actual
implementation of your system.
 This is different from analysis, which focuses on
understanding what will be built.
 Design is an iterative process (possibility to come
back to the previous first step and revise things).
 Analysis and design are highly iterative &
interrelated.
 Similarly design & Programming are iterative &
interrelated.

215
 Persistence Model
Use case
State Chart Diagram
Model

Class Model Class Model (Design) Deployment Model

(Analysis)

User Interface Collaboration

Prototype Component Model
Diagram

216
1. Are we going to develop component based application or a
pure object oriented application?
• In component based development your software is
developed from collection of components.
• In pure object oriented application development your
software is built from a collection of classes.
2. Are we going to use a business architecture?
 Will you follow a common business architecture?

3. Are we going to use a technical infrastructure supported

by common software developers like Enterprise Java Beans,
COBRA?
• Will you follow a common technical architecture?
4.Which non functional (technical) and constraints are going
to be implemented?

217
 Layering is the concept of organizing your
software design into layer collections of classes
or components that full fill a common purpose,
such as implementing your user interface or the
business logic of your system.
 Class type architecture increases the:
o Extensibility
o Maintainability &
o Portability of the systems you create.

218
 User Interface
(Boundary) Classes

Controller (Process)
Classes

System
Business/Domain
Classes
Entity or Analysis Classes

Persistence Classes

Permanent Storage

21
9
System Classes
 Are only allowed to send message to other system
classes, even though each type of class is allowed to
send messages to system classes.
 Provide Operating System specific functionality for
your application, isolating your software from the
operating system by wrapping OS-specific features, in
creating the portability of your application.
Persistence Classes
 Used for storing objects, we can create, update,
retrieve, delete objects.
 Encapsulate the capability to store, retrieve, delete,
create objects permanently without revealing details of
the underlying storage technology.

22
0
Business/ Domain Classes
 Implement the concepts pertinent to your business domain.
 Enables you to encapsulate the basic business functionality
without having to concern yourself with user interface, data
management, system management
Controller/Process Classes
 Implement business logic that involves collaborating with
several business/domain classes or even other controller/
process.
What is the advantage of layering?
 To make our system portable (i.e from one OS to another)
 This makes one system maintainable (because one problem
will be limited in one layer)

221
  Also called state, state transition, state machine.
 Used to explore the different state a class can be in (an actor, subsystem and

component can be in its life time).

 UML state chart diagram depicts the various states that an object may be in &

the transitions between those states.

 Transitions are the result of method invocation and often reflect business rules.

 To understand complex classes better, particularly that act in different manners

depending on their states you should develop one or more UML state chart
diagram
State chart diagrams: is a notation for describing the sequence of states an object
goes through in response to external events.
 A state is a condition that object satisfies.

 The state chart diagram focuses on the transitions between states as a result of
external events for an individual object
 A small solid black circle indicates the initial state.

 A circle surrounding a small solid black circle indicates a final state.

 A state is depicted by a rounded rectangle.

 A transition represents changes of state triggered by events, conditions, or time

222
1. Identify the creation/initial state
2. Identify the final states , if any.
3. Identify as many other applicable, “real world”
states as possible.
4. Identify potential sub states.
5. Identify the transitions leaving the state.
6. Identify the target state to which a transition nature
leads.
 Class diagrams model the static of your system,
 Sequence diagrams model the logic of usage
scenarios
 State chart diagram models the behavior of
complex class.

223
  Shows collaboration of different objects in our system.
 Similar to sequence diagram in analysis which shows class & object
collaboration.
 Depicts a bird eye view of the interaction between objects.
 Shows the message flow between objects in Object Oriented application
and also, imply the basic associations (relationships) between classes.
Drawing Collaboration Diagram
 Collaboration diagrams are usually drawn in parallel with class diagram
and sequence diagram.
1. Identify the scope of the diagram.

2. Identify the objects.

3. Identify the relationships between the objects.

4. Identify the messages passed between the objects.

 UML sequence diagrams and UML collaboration diagrams are

interchangeable & their usage often boils down to a matter of personal
taste.

224
 Component diagrams depicts how components are wired together to
form larger components and or System.
 Used both to analyze and design your component based software.
 The goal of component modeling is to distribute the classes of your
system in to larger-scale, cohesive component.
 Identifying the component is the design equivalent of identifying
packages.
 Component diagrams are different in terms of nature and behavior.
 Component diagrams are used to model physical aspects of a system.
 Now the question is what are these physical aspects? Physical aspects
are the elements like executable, libraries, files, documents etc which
resides in a node.
 So component diagrams are used to visualize the organization and
relationships among components in a system. These diagrams are also
used to make executable systems.
 Component diagram cannot be matched directly with other UML
diagrams discussed so far. Because it is drawn for completely different
purpose.
225
 Five steps exist, typically performed in an iterative manner, to
componentize your object design.
1. Handle non business/domain classes

2. Define class contracts

 Class contracts: is any service/behavior of a class that is requested of it.
 It is a public method that directly responds to a message from other
classes.
3. Simplify inheritance & aggregation hierarchies.
4. Identify potential domain component.
 Domain component: is a set of classes that collaborate among themselves to
support a cohesive set of contracts.
 Server classes belong in component
 Client classes don‟t belong in component
5. Define domain-component contracts.

226
 Deployment diagrams are used to visualize the
topology of the physical components of a system
where the software components are deployed.
 So deployment diagrams are used to describe the
static deployment view of a system.
 Deployment diagrams consist of nodes and their
relationships.
 Developed by architects, networking engineers &
system engineers.
 Depicts a static view of the run-time configuration
of processing nodes and the components that run
on those nodes.
 Deployment models are typically developed in
parallel with component model.
227
Steps to develop deployment model
1. Identify the scope of the model
Deployment configuration for a single application
2. Identify the distribution architecture.
3. Identify the nodes & their connections.

4. Distribute components to nodes.

5. Model dependencies between component.

228
 User interface design is a difficult task requiring a wide
range of skills.
 The principles of user interface design are intended to
improve the quality of user interface design
1. The structure principle: The structure principle is
concerned with overall user interface architecture.
2. The simplicity principle: The design should make
simple, common tasks easy, communicating clearly and
simply in the user's own language, and providing good
shortcuts that are meaningfully related to longer
procedures.
3. The visibility principle: The design should make all
needed options and materials for a given task visible
without distracting the user with extraneous or redundant
information.

229
4. The feedback principle: The design should keep users
informed of actions or interpretations, changes of state or
condition, and errors or exceptions that are relevant and of
interest to the user through clear, concise, and unambiguous
language familiar to users.
5. The tolerance principle: The design should be flexible
and tolerant, reducing the cost of mistakes and misuse by
allowing undoing and redoing, while also preventing errors
wherever possible by tolerating varied inputs and sequences
and by interpreting all reasonable actions reasonable.
6. The reuse principle: The design should reuse internal
and external components and behaviors, maintaining
consistency with purpose rather than merely arbitrary
consistency, thus reducing the need for users to rethink and
remember.

230
The end!
23
1