SOFTWARE ENGINEERING LECTURE NOTES

By Prof. J K Bada
Date: February 16, 2024

THE PROCESS OF OBJECT MODELLING

In performing object-oriented analysis (OOA), like any other systems analysis method, the purpose
is to get a better understanding of the system and its requirements. In other words, OOA requires
that we identify the objects, their data attributes, associated behavior, and associations that support
the business system requirements. We perform object modeling to document the identified objects,
the data and behavior they encapsulate, plus their relationships with other objects.
There are four general activities when performing object-oriented analysis and they are as follows:
1. Modeling the functions of the system
2. Finding and identifying the business objects
3. Organizing the objects and identifying their relationship
4. Modeling the behavior of the objects.

Modeling the functional description of the system

The approach that is commonly used to model the functional aspects of the system is called use
case modeling.
Use case modeling is the process of modeling a system’s functions in terms of business events,
who initiated the events, and how the system responds to the events.
Use case model identifies and describes the system functions from the perspective of external users
using a tool called use cases.
A use case is a behaviorally related sequence of steps (a scenario), both automated and manual,
for the purpose of completing a single business task.

An actor represents anything that needs to interact with the system

to exchange information. An actor is a user, a role, which could as
well be an external system as well as a person.
An actor initiates system activity, a use case, for the purpose of
completing some business task. An actor represents a role fulfilled
by a user interacting with the system. The actor would be the student
and the business event, or use case, would be enrolling in a course.

Actor symbol

In many information systems business events are triggered by the

Use case symbol calendar or the time on a clock. Consider the following examples:

• The billing system for a credit card company automatically generates its bills on the fifth
day of the month (billing date).

1
 • A bank reconciles its check transactions everyday at 5:00 PM.
• On a nightly basis a report is automatically generated listing which causes have been closed
to enrollment (no open seats available) and which courses are still open.
These events are examples of temporal events
A Temporal event is a system event that is triggered by time.
An actor of temporal event can be time.
Use cases provide the following benefits:
• As a basis to help identify objects and their high level relationships and responsibilities.
• A view of system’s behavior from external person’s viewpoint.
• An effective tool for validating requirements.
• An effective communication tool.
• As a basis for a test plan.
• As a basis for a user’s manual.

There are many approaches to begin use case modeling. They include prototyping, user and
business analyst interviews, and other fact-finding techniques
The following are the steps involved in use case modeling during systems analysis.

Step 1: Identify Actors and use cases. Actors and use cases of a system can be identified by
interviewing users of the system. Another excellent approach to find potential actors and use cases
is by analyzing the context model diagram of the system.

Step 2: Construct a Use Case Model. Once the use cases and actors have been identified, a use
case diagram can be used to graphically depict the system scope and boundaries. The partitioning
of system behavior into subsystems is very important in understanding the system architecture
and is key to defining your development strategy – which use cases will be developed first and by
whom.

2
Member services system context model diagram

Club Member
Accounts
Promotion Receivable

Member order
Member credit status

Warehouse

Potential
Various inquiry responses Revised packing order
Member New subscription New promotion
Member
Subscription order Services system Subscription program

Subscription Renewal
Various
Sales reports

Various
Resubscription
Past Member Offer Promotion reports Marketing
Department

various subscription reports

Member
Services

Various member reports

3
Step 3: Document the Use Case Course of Events. For each use case identified, we must now
document the use case’s narrative, which includes the typical course and its alternative courses.
During this step the use cases are documented to contain only general information about the
business event. The goal is to quickly document all the business events (use cases) in order to
define and validate requirements.

Step 4: Define the analysis Use Cases. Once all requirements use cases have been reviewed and
approved by users, each use case will be refined to include more information in order to specify
the system functionality in detail. The resulting use cases are called analysis use cases and still
should be free of any implementation details. These use cases will be further refined in object-
oriented design to specify the how or implementation specifics.

Actor Use Case Name Use Case Description

Potential member SUBMIT NEW Potential member joins the club by
SUBSCRIPTION subscribing
Club Member PLACE NEW Club member places order
MEMBER ORDER
Marketing SUBMIT NEW Marketing initiates a promotion
PROMOTION
Time GENERATE ANNUAL Print annual sales analysis report
SALES ANALYSIS

Finding and Identifying the Business Objects

Use case modeling breaks down the entire scope of the system into use cases. The following steps
are involved in use case modeling to identify and find business objects for object modeling during
systems analysis.

Step 1: Find the potential objects. This step is accomplished by reviewing each use case
to find nouns that correspond to business entities or events.
Step 2: Select the proposed objects. Not all the candidates on our list represent good
business objects. At this time, we need to clean up our list by removing the nouns
that represent:
• Nouns outside the scope of the system,
• Unclear nouns that need focus,
• Nouns that are really actions or attributes.

4
 Subscription subsystem

Order subsystemInitiates Club member Submit change Potential

of address member
Potentialmember
Maintain
member order Submit new
subscription I

Place new Submit

member order resubscription

Make purchase
inquiry Resubscription Past member
program

Submit new
Initiate member
subscription
program
Operations subsystem Time
Promotion subsystem

Make account inquiry

Generate quarterly Marketing
promotion analysis
Generate quarterly
membership analysis

Submit new
Generate annually promotion
membership analysis

Generate quarterly
sales analysis

Generate annually
sales analysis

5
What is a business rule?

Basically, a business rule is a compact statement about an aspect of a business. The rule can be
expressed in terms that can be directly related to the business, using simple, unambiguous language
that's accessible to all interested parties: business owner, business analyst, technical architect, and
so on.

It's a constraint, in the sense that a business rule lays down what must or must not be the case. At
any particular point, it should be possible to determine that the condition implied by the constraint
is true in a logical sense; if not, remedial action is needed. This interpretation, which might be
described as Boolean from a software perspective, is the main reason that the term business logic
is so commonly used.

GUIDE (an IBM-oriented industry user group) produced a useful, quite widely quoted definition
of a business rule: "a statement that defines or constrains some aspect of the business. It is intended
to assert business structure or to control or influence the behavior of the business." This is as close
as you're likely to get to a satisfactory short statement of what we mean by a business rule. Of
course, one rule does not a business make, but this simple idea is a building block from which we
can construct systems of surprising power.

Capturing the logic of an entire business would require probably many thousands of rules; a
smaller subsystem, perhaps several hundred. Even so, the individual rules are small and relatively
easy to understand, simplifying such tasks as discovery, definition, review, and maintenance.

All this may sound a bit daunting, but individual rule statements can be—and indeed ought to be—
quite straightforward. The following examples give an idea of what you can expect. These are just
isolated examples and aren't meant to demonstrate any particular business area, but they do show
the size and complexity of rule we'll be dealing with.

R101 A valid inbound Contact must be associated with a specific Customer.

R102 A withdrawal from an account may be made only if the account balance is greater than zero.
R103 A Customer must be considered as high worth if at least one of the following is true:

- The Customer is a VIP,

- The Customer has a current balance of at least X,

- The Customer has held an account for more than Y years.

The way we build software

To understand the importance of business rules, we need to take a look at how we build information
systems. Figure 1-1 shows a sketch of the system development process as it exists in most places
today.

6
Figure 1-1. The current development process

Of course, this is highly simplified and hides a lot of detail. For instance, deployment of the
software also involves some form of testing to make sure that the installation has fully completed
and that the new software is interacting correctly with other system elements. Nonetheless, even
this high-level view is enough to point out some features that should worry us.

• The business owner—the person who needs the software and is presumably paying for its
development—is somewhat remote from the process. Once an initial description of the
business need has been created, typically in the form of a requirements specification,
involvement is limited to interaction through technical specialists, mainly because the
materials generated and used in development are difficult to understand without special
training and experience.
• The process contains an implicit acceptance of frailty. It's taken for granted that the code
produced will contain errors and that a significant amount of testing may be necessary—
perhaps up to a third of the project. Even worse, the testing has to be terminated when the
number of errors has reached an acceptable level. Any changes to the software may
introduce new errors, so the opportunities to improve quality by refining the process are
limited. A certain likelihood of undetected residual problems always has to be accepted.
• The process relies a lot on descriptive material that has to be interpreted by people with the
right kinds of skills to turn it into development products. Typically, analysts interpret the
business requirements to produce a design document, and developers interpret the design
document into the source code. This sequence introduces many possible places for
misunderstandings that may not get detected until very late in the process.

7
 • The process is very labor intensive. Almost every major step, apart from generation of the
deployable software from the source code, is undertaken by manual effort. Not only that,
the people involved require specialized skills, making them difficult to find and expensive
to retain.
• The process is fairly slow. For a large system, moving from a requirements specification
to operational software can take years. Some big software projects have been abandoned,
at huge cost, because the needs of the organization were changing more quickly than the
software could be developed. Even a small system can take weeks or months of
development before it's delivered.
• There's little separation of concerns. For example, business needs and deployment
constraints tend to be integrated only in the mind of the developer. The resulting source
code often tangles these together in a way that's very difficult to unpick. This makes it
difficult to do things that could be highly beneficial to the business, such as moving a
working system to a newer technology base to take advantage of lower hardware and
support costs.

Frameworks

We'll start with frameworks because, conceptually, they should be considered first. It's only fairly
recently that people have started to discuss such things explicitly, and many—perhaps most—
organizations stumble into more detailed activities without having any clear framework in mind.

From our perspective, the purpose of a framework is to define the way in which we're going to
describe the information system of an organization. "System" here does not necessarily mean just
an automation system; we need to think about people too. A framework, in the sense that we're
describing it, is a piece of virtual scaffolding that provides places to hang some less abstract notions
that come later. You can't build a physical example of it, but you need its help to structure your
progress into the unknown.

A framework will give you

• A checklist for the dimensions that you need to consider in modeling

• A context for understanding the relationships among various information system properties
• A consistent baseline vocabulary for communication within the organization

The best-known framework is probably the Framework for Enterprise Architecture, first described
by John Zachman (1987) and usually just referred to as "the Zachman Framework." Zachman
himself consistently and carefully explains that the framework is intended to be an aid to thinking
and should not be taken as a detailed catalog of parts that can be bolted together directly to form
an information system.

The distinctive feature is its arrangement of concerns in a two-dimensional grid. The rows of the
grid represent different viewpoints, or perspectives, that can be taken when looking at an
information system. The columns represent various aspects of the system, corresponding to the
different kinds of questions that could be asked about it.

8
We'll start with the rows and the perspectives they cover. All perspectives are equally valid, and
all can coexist. However, there's normally an evolution of ideas, and so the rows are arranged
(downward) in an order that roughly corresponds to the sequence of their appearance during the
growth of an information system. Table 2-1 describes the purpose of each row.

Table 2-1. Rows of the Zachman Framework

Row Viewpoint (Perspective) Typical Viewpoint of
1 Scope (contextual) Planner
2 Enterprise model (conceptual) Owner
3 System model (logical) Designer
4 Technology model (physical) Builder
5 Detailed representations Subcontractor
6 Functioning enterprise -

The columns (see Table 2-2) represent the various dimensions that need to be considered at each
level of an information system. Again, these are not alternatives: All dimensions have to be taken
into account to give an adequate all-round picture. The questions echo the well-known lines by
Kipling from his poem "The Elephant's Child":

I keep six honest serving-men

(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

Table 2-2. Columns of the Zachman Framework

Column Aspect Answers the Question
1 Data What
2 Function How
3 Network Where
4 People Who
5 Time When
6 Motivation Why

The row/column grid provides a set of coordinates, each of which represents a particular aspect as
seen from a specific viewpoint. The cells at each intersection can be used to hold a description of
the kind of element that's relevant. The examples suggested by Zachman for each cell are shown,
slightly abbreviated, in Table 2-3.

9
Table 2-3. The Zachman Framework
What How Where Who When Why
Scope List of List of List of locations List of List of List of goals
things processes organizations events
Enterprise Model Semantic Business Business Workflow Master Business plan
model process logistics model schedule
System Model Logical Application Distributed Human interface Processing Business rule
data model architecture system architecture structure model
architecture
Technology Physical System design Technology Presentation Control Rule design
Model data model architecture architecture structure
Detailed Data Program Network Security Timing Rule
Representations definition architecture architecture definition specification
Functioning Data Function Network Organization Schedule Strategy
Enterprise

Because the cell contents are only examples, we don't need to get too hung up on their precise
interpretation. It's also worth repeating that this is a framework for thinking about information
systems, not a decree that they be subdivided into exactly 36 boxes—or 30 if you leave out the
Functioning Enterprise row. As an example, take the How and Who cells of the Enterprise Model
viewpoint. It maybe wasn't so common in 1987, but business processes today are often
implemented through automated workflow systems. Their separation in the framework is the result
of an emphasis on different aspects—in this case, how things happen versus who does things; it's
not meant to imply that these features must always be forcibly separated into different packages,
models, tools, or any other kind of compartment. A key point to be aware of is that joining cells
together can result in overlooking a particular aspect or a viewpoint, and you need to be sure that
the use of a common tool, notation, or other device does not cause an important facet to be
neglected.

The Testing Life Cycle

The concept of a testing methodology defines the steps and tasks to test a software
system. The methodology consists of procedures to follow for each major phase of work.
The procedures specify what should take place during each phase of the work and spell
out individual sub-phases and tasks in considerable detail. The intent is to bring
discipline to the manner in which the testing is carried out and to ensure that required
steps are completed in an appropriate sequence.

10
It is necessary to have a testing methodology that is closely integrated with the
development process and that brings discipline to the manner in which the what-to-test,
when-to-stop, and who-does-the-work questions are answered. Testing requirements at
each step of development have to be defined and, in effect, a "testing life cycle" has to
exist side by side with the development life cycle.

Integrating Testing within the Life Cycle

Project Initiation
Develop broad test strategy.
Establish the overall test approach and effort.
Requirements
Establish the testing requirements.
Assign testing responsibilities.
Design preliminary test procedures and requirements-based tests.
Test and validate the requirements.
Design
Prepare preliminary system test plan and design specification.
Complete acceptance test plan and design specification.
Complete design-based tests.
Test and validate the design.
Development
Complete the system test plan.
Finalize test procedures and any code-based tests.
Complete module or unit test designs.
Test the programs.
Integrate and test subsystems.
Conduct the system test.
Implementation
Conduct the acceptance test.
Test changes and fixes.
Evaluate testing effectiveness.

Testing Through Reviews

Evolution of Reviews

One crucial element in any testing life cycle is reviews. What is a review? Reviews of
software began evolving as a management control tool. During any project, management

11
requires a means of assessing and measuring progress. Are we ahead of or behind where
we expected to be? Will we complete the work as planned? Such questions need to be
answered reliably, and the so-called progress review evolved as the means of doing it.
The manager designated various points along the life cycle and "reviewed" the status of
the project at those times.

The results of these early reviews proved to be bitter experiences for many project
managers who had to learn the hard way how long a project could remain at 90 percent
complete! "True" progress could not be measured by counting tasks
completed unless there was a reliable way of gauging the quality of the work performed
and knowing that it would not have to be redone or changed later. Thus we saw the
emergence of "technical reviews" to examine the quality of technical work and serve as
input into progress reviews. We now see many different types of reviews throughout the
development life cycle. Virtually any work produced during development can be and is
reviewed. This includes requirements documents, designs, code logic, test plans, test
documentation, and so forth.

What Is a Review?
A review is any of a variety of activities involving
▪ Evaluations of technical matter
▪ Performance by a group of people working together

The objective of any review is to obtain reliable information, usually as to status and/or
work quality.

There are many different types of reviews:

▪ Requirements ▪ Procedural ▪ Test design
▪ Specifications ▪ Documentation ▪ Test procedures
▪ Design ▪ Conversion ▪ Test plan
▪ Coding ▪ Installation
▪ Post-implementation
Reviews as a Testing Technique
Most practitioners consider reviews and testing as completely different things, arising
from the old view of testing as a follow-on activity that involved executing test cases.
When testing is thought to be the measurement of software quality, it is clear that reviews
are a general class of testing methods. In the university a graduate student can expect to
undergo thesis reviews as his or her research program is formulated. Such reviews are
conducted to ensure that the completed dissertation will meet requirements. They "test"
interim work, which passes and fails as in more traditional examinations. Our treatment

12
of software reviews should be similar. Reviews are the only testing technique available in
the early phases of development work, and it is essential that we view them as tests and
make sure that they are effective. This means planning carefully what we will test
(review), what it will take to pass (the expected results and when to stop), and who will
do the work (responsibilities).

Reviews may be formal or informal. We call a review formal if the participants feel
responsible for accurate evaluations and produce a written report of their findings to
management. That is quite different from more informal reviews, which involve the
sharing of opinions between practitioners. It is the formal review that is designed to
provide reliable information about technical matters and may be considered a testing
technique.

The Review Plan

The first step toward achieving an effective testing life cycle is to select a series of formal
review checkpoints. The reviews may be placed anywhere along the development cycle.
They are generally conducted as each major work result is produced and serve as
completion checkpoints. The number of reviews needed and their placement in the life
cycle may vary considerably, depending on the size and nature of the software project.

Some important potential review times are listed with their purpose or expected result. I
find that the conduct of virtually all these reviews is important to effectively test even
modest-sized software efforts.
Some Important Review Checkpoints
Review Typical Purpose or Expected Result
System Understand what the system is intended to do.
Requirements
Software Approve the requirements specification and initiate
Requirements preliminary design.
Master Test Plan Approve overall test strategy and approach.
Preliminary Establish a preliminary design baseline; concur in the basic
Design design approach for the software and the tests.
Critical Design Approve detailed design; authorize start of coding and test
implementation.
Module Reviews Approve unit completion and release of module to formal
testing.

13
 Some Important Review Checkpoints
Review Typical Purpose or Expected Result
System Test Concur in completion of system testing and authorize start of
acceptance testing.
Acceptance Test Accept the product; approve operational implementation.

For each formal review that is established a plan is needed to structure the review and
provide answers to the what-is-to-be-tested, when-to-stop, and who-does-the-work
questions. At a minimum the review plan should specify:
▪ Who is to attend
▪ Information required before the review may begin
▪ Preconditions that must be completed before the review is conducted
▪ Checklists or other indications of what will be covered
▪ End conditions or criteria that must be met for the review to be completed
▪ Records and documentation to be kept.

This plan should also assign responsibility for preparing and training review
participants, for scheduling and organizing the review, and for reporting results.

A hypothetical review plan follows. This is an outline plan for a review conducted at the
completion of the preliminary design phase of a project. This review tests the quality of
the basic design and ensures that the project is ready to proceed into detailed design
work.

Testing Requirements through Requirements-Based Test Case Design

Recognizing that requirements become clearer and that faults within them are recognized
more readily when we understand how to test them has led to the practice of designing
some test cases at requirements time. Such cases are called Requirements Based as they are
derived solely from the external specification or requirements for the software. Since
information about the software design and data structures is not available, the
requirements-based tests designs may be incompletely specified. However, the purpose
is to derive requirements-based test situations and use them as a test of requirement
understanding and validation.

As examples, consider the following:

Example 1: Dealing with Incompleteness

When requirements are found to be incomplete, the tester can use a test case to focus the
missing information and get it clarified. For example, if the behavior or response to some

14
input is not specified, a test case can be designed with that input and the question asked,
"What should the system do in this case?" Such directed questions using specific instances
and cases are much more effective than general comments that the requirements are
incomplete.

Example 2: Dealing with Imprecision

Similarly, when requirements are fuzzy or imprecise, a test case may be constructed and
the question asked, "Is this the result I should have in this situation?" The specific instance
will focus attention on the imprecise answer or result and ensure that it is examined
carefully.

The STEP testing methodology stresses completion of requirements-based test

design before software design and coding is started. This is based on the conviction that
taking the time and effort to develop a thorough test from the requirements pays for itself
many times over through improved and more validated requirements before the
software design and coding activity begins.

Testing Requirements through Prototypes or Models

A second important strategy for testing requirements (determining whether any
requirements are missing or whether the needs can be simplified) is through the use of
prototypes or test "models." The technique consists simply of building a model or
prototype system not with the intent to use it, but to test and confirm the understanding
of the true requirements.

The Benefits of Models

▪ A picture is worth a thousand sentences,
▪ An example is worth a thousand pictures!

Test models are especially useful when so little is understood about the requirements that
it is necessary to gain some "experience" with a working model. Such models recognize
that requirements change with experience and that one of the best ways to test for proper
understanding of true requirements is to use a system (or at least as much of a skeleton
as may practically be provided for test purposes).

15
The popular practice of incremental development is an extension of the prototype
concept. Incremental development simply means that the process of establishing
requirements and designing, building, and testing a system is done in pieces or parts.
Rather than attempting to solve a "total" problem, one selects a part of the problem and
designs, builds, and implements a system to address it. Then, based on the experience with
that subpart, one selects another part of the problem, and so on. The advantage is that
requirements for later increments do not have to be specified prematurely and can be
adjusted on the basis of working experience.

Some practical experience with incremental development suggests that it is best not to
specify too many increments in advance. Most organizations try to define (or at least
foresee) all of the increments in the initial organization of the effort. They quickly discover
how much those later increments change as a result of changing requirements. The most
dramatic changes are when the client or customer says, "I like what I have now and do
not want any additional increments!" Here the testing of requirements achieved as a
result of a working prototype (or stage of incremental development) has been so effective
that all additional requirements are dropped and no longer seem to be necessary. As
Gerry Weinberg has pointed out, not every organization is quick to recognize such a
situation as positive. Project managers may feel that they have "failed" when further work
is canceled. Only later might they realize that the "ability to decide when to stop is a
feature, not a failure!"

Other Requirements Testing Techniques

Testing for missing requirements is aided by any effort to organize or "structure" the
existing list of requirements. Indexing and organizing by function, or by affected data
element or system output so that related requirements are grouped together, is always
useful, especially as a preparatory step to a formal review. Checklists can also be
extremely useful as reminders of commonly overlooked requirement areas or previous
omissions. When requirements are grouped together they can be analyzed in a block for
simplicity, redundancy, and consistency. With a look at the entire group, one can make
an effort to formulate simpler or higher-level requirements that specify the same needs
more effectively, and the unnecessary requirements can simply be dropped out.

Automated tools and support aids for requirements testing are not well developed and
currently offer little benefit. Experimentation is taking place with specification and
requirements definition "languages." Such languages provide a vehicle for stating
requirements in quasi-structured English and permit some forms of automated analysis.
Most of the benefit arises from the discipline imposed in organizing the specification and
then listing the test explicitly with each specification. As emphasized earlier, insisting on

16
testability greatly improves the ability to understand and validate the requirements.
Other automated aids include indexing programs to group related requirements,
paragraph analyzers to flag confusing and overly complex sentences, and decision-table
or cause-and-effect graph analyzers.

Anything that helps to make requirements more "testable" improves our ability to
simplify or eliminate unnecessary requirements. Specifying requirements in the form of
decision tables or as cause-and-effect graphs is an example. The use of a table to show
possible conditions and specify intended actions provides an implicit test to determine
success. Thus requirements provided in the form of a decision table (or as an equivalent
cause-and-effect graph) are inherently testable and can usually be validated quite easily.

There is clearly no simple formula for testing requirements well. Good reviews are the
essential ingredients. All the automated aids play only a minor role in actual
requirements testing practice.

Reference

Business rules and Information Systems: Aligning IT with Business Goals, By Tony Morgan,
March 18, 2002.

17