Creating Models in Design

It is important when working on a software development project not

to jump right into creating code to solve the problem. Instead,
making the right product involves understanding the full
requirements of your product and using good design.

The design step falls between understanding your requirements

and building the product. It iteratively deals with both the problem
space and the solution space. The design should also present and
describe concepts in a way that users and developers both
understand, so they may discuss using common terms.

Design is such an important step in software development, and

there have been many approaches developed over time to help
make this process easier. For example, some design strategies and
programming languages have been created for specific kinds of
problems.

One approach to help make the design process easier is the object-
oriented approach. This allows for the description of concepts in
the problem and solution spaces as objects—objects are a notion
that can be understood by both users and developers, because
object-oriented thinking applies to many fields. This shared
knowledge makes it possible for users and developers to discuss
elements of complex problems. Object-oriented programming with
object-oriented languages is therefore a popular means for solving
complex problems.

A good design does not just jump from a concept within the
problem space to dealing with it in the solution space. Object-
oriented design is no exception. As reviewed in Module 1, object-
oriented design consists of:

• Conceptual design uses object-oriented analysis to

identify the key objects in the problem and breaks down the
problem into manageable pieces.
• Technical design uses object-oriented design to further
refine the details of the objects, including their attributes and
behaviours, so it is clear enough for developers to
implement as working software.

Object-Oriented Design | 21
These design activities happen iteratively and continuously.

The goal during software design is to construct and refine “models”

of all the objects of the software. Categories of objects involve:

• entity objects, where initial focus during the design is

placed in the problem space

• control objects that receive events and co-ordinate actions

as the process moves to the solution space

• boundary objects that connect outside services to your

system, as the process moves towards the solution space

Software models help you understand and organize the design

process for the objects. Design principles and guidelines are
applied to complex problems: to simplify objects in the model and
break them down into smaller parts and to look for commonalities
that can be handled consistently. Models should be continuously
critiqued and evaluated to ensure the original problem is addressed
and qualities such as reusability, flexibility, and maintainability are
satisfied. Models also serve as design documentation for your
software. In fact, models are often mapped to skeletal source code,
particularly for an object-oriented language like Java.

Software models are often expressed in a visual notation, called

Unified Modelling Language (UML). Object-oriented modelling
has different kinds of models or UML diagrams that can be used to
focus on different software issues. For example, a structural model
might be used to describe what objects do and how they relate.
This is analogous to a scale model of a building, which is used in
architecture.

Now that you have an understanding of the roles models play in

design and of the relationship between models and coding
languages, the next lesson will turn to reviewing the history of
programming languages.

Object-Oriented Design | 22
Evolution of Programming Languages

Language is the word that we use to describe a system for

communicating thoughts and ideas with each other. Writing,
reading, speaking, drawing pictures, and making gestures are all
part of language! Languages must be continually evolving in order
to stay “alive” and be used by people.

Programming languages are no exception to this, and just like

traditional languages, they have evolved over time. Often,
programming languages evolved to provide solutions or more
effective solutions to needs or problems that the current
programming languages cannot meet. New languages or ideas may
also arise to address new data structures. The ideas used in
computer languages caused shifts in programming paradigms.

DID YOU KNOW?

An example of design strategies and programming languages suited

for specific kinds of problems that you may be familiar with is top-down
programming.

Top-down programming is generally used to solve data- processing

problems. This design strategy consists of mapping processes in the
problem to routines to be called, beginning with the “top” process.
Generally, this design is expressed through a tree of routines.

These routines would be implemented in a programming language

that supported subroutines.

It is important to know the history of programming paradigms. As a

software developer, you may still encounter systems that use older
languages and design paradigms. As well, although object-oriented
programming is a powerful tool, there may be problems that are
best or more efficiently solved with another paradigm. Finally, it is
important to understand this history, as new languages may not
force new structures but only modify existing ones. Some old ways
of doing something or old paradigms may be expanded on so
much that the new structures may be difficult to recognize.
Knowledge of the past may help.

Object-Oriented Design | 23
Below is a table summarizing major programming paradigms in the history of programming languages.
Programming Time Solutions afforded Unresolved issues
Language period by Programming Language of Programming Language

COBOL and Fortran followed an imperative paradigm that broke up large If changes are made to the data,
COBOL 1960s
programs into smaller programs called subroutines. then subroutines might run into
Fortran cases where the global data is not
As computer processing time was costly, it was important to maximize what was expected. Better data
processing performance. To solve this problem, global data was used so management is needed to avoid
that data was located all in one place in the computer’s memory and these problems.
accessible anywhere for a program. This meant that subroutines only had to
go to one place to access variables.

Subprogram
B

Subprogram Subprogram
A C

Global
Data

Object-Oriented Design | 24
Programming Time Solutions afforded Unresolved issues
Language period by Programming Language of Programming Language
Algol 68 Early In the 1960s, global data was used. However, any changes to the data may Towards the mid-1970s, computer
result in issues for the subroutines. processing time became less
Pascal 1970s
expensive. At the same time, human
The solution introduced the idea of scopes and local variables – subroutines labour was more expensive and
or procedures could each have their own variables. became the more time-consuming
factor in software development. The
advances in computer processing
Procedure allowed more complex problems to
Procedure C
B be asked of computers. But it also
Nested Procedure
meant that software was quickly
Procedure Local Data growing, and having one file to
A maintain programs was difficult to
maintain.
Global
Data

These languages supported the use of abstract data type, which is defined
by the programmer and not built into the language. This is a grouping of
related information that is denoted with a type. This allows information to be
organized in a meaningful way.

By having data bundled and passed into different procedures through the
use of data types, this means that a procedure can be the only one that
modifies a piece of data. There no longer needs to be a worry that data will
be altered by another procedure.

Object-Oriented Design | 25
Programming Time Solutions afforded Unresolved issues
Language period by Programming Language of Programming Language
C Mid- By the mid-1970s computers were faster and able to tackle more complex It is not easy for an abstract data
problems. However, this meant that the programs of the past were quickly type to inherit from another in these
Modula-2 1970s
becoming too big to maintain. This led to new languages, that provided a languages. This means that
means to organize programs into separate files, and allow developers to although as many data types as
more easily create multiple, but unique, copies of abstract data types. wanted can be created, one type
cannot be declared an extension of
another.

Data Data

Procedure Procedure
A B Procedure C

Modules
For example, in the programming language C, each file contained all the
associated data and functions that manipulated it, and declared what could
be accessed through a separate file called a header file.

Object-Oriented Design | 26
Programming Time Solutions afforded Unresolved issues
Language period by Programming Language of Programming Language
Object- 1980s Although programs were become easier to manage through abstract data Object oriented programming is the
types, there was still no way to for data types to inherit from each other. The predominant programming
Oriented to
concepts of object-oriented design became popular during this time period paradigm now.
Programming present as a solution to these problems.
(Java, C++,
C#, etc.) Object-oriented design seeks to:
• make an abstract data type easier to write
• structure a system around abstract data types called classes
• introduce the ability for an abstract data type to extend another
through a concept known as inheritance

Data Data

Procedure Procedure
A B Procedure C

Classes

Object-Oriented Design | 27
Programming Time Solutions afforded Unresolved issues
Language period by Programming Language of Programming Language

Under this paradigm, software systems can be built of entirely abstract data
types. This allows the system to mimic the structure of the problem—in other
words, the system can represent real-world objects or ideas more accurately.

Class definition files in object-oriented programming replace the files in C

and Modula-2. Each class defines a type with associated data and functions.
These functions are also known as methods. A class acts like a factory,
making individual objects all of a specific type. This allows data to be
compartmentalized and manipulated into its own separate classes.

Object-Oriented Design | 28
Four Design Principles

As described in the first lesson of this module, object-oriented

programming allows you to create models of how objects are
represented in your system. However, to create an object-oriented
program, you must examine the major design principles of such
programs. Four of these major principles are: abstraction,
encapsulation, decomposition, and generalization.

Abstraction

Abstraction is one of the four major design principles that will be

examined in this lesson. Abstraction is one of the main ways that
humans deal with complexity. It is the idea of simplifying a concept
in the problem domain. Abstraction breaks a concept down into a
simplified description that ignores unimportant details and
emphasizes the essentials needed for the concept, within some
context.

An abstraction should follow the rule of least astonishment. This

rule suggests that essential attributes and behaviours should be
captured with no surprises and no definitions that fall beyond its
scope. This prevents irrelevant characteristics from becoming part
of an abstraction and helps to ensure that the abstraction makes
sense for the concept’s purpose.

Program constructs includes elements such as functions, classes,

enumerations, and methods. In object-oriented modelling,
abstraction pertains most directly to the notion of a class. When
abstraction is used to determine the essential details for some
concept, those details may be defined in a class. Any object created
from a class has the essential details to represent an instance of
some concept, but it may have some individual characteristics as
well. Think of a cookie cutter used to create gingerbread men. Each
instance of a cut cookie belongs to the class of “gingerbread men”
and share essential characteristics such as head, arms, and legs,
even if they are decorated differently.

Object-Oriented Design | 29
Context or a specific perspective is critical when forming an
abstraction. This is because context might change the essential
characteristics of a concept. For example, consider the essential
characteristics of the concept of a person. This can be hard to
understand without context, as this concept is vague and the
person’s purpose is unknown. But, in a gaming app, the essential
characteristics of a person would be in the context of a gamer. In a
running exercise app on the other hand, the essential characteristics
of a person would be in the context of an athlete. It is up to the
designer to choose the abstraction that is most appropriate to the
context of the software development, and the context must be
understood before creating an abstraction.

The essential characteristics of an abstraction can be understood in

two ways: through basic attributes and through basic behaviours
or responsibilities.

Basic attributes are characteristics that do

not disappear over time. Although their
values may change, the attributes
themselves do not. For example, the
concept of a lion may have an age attribute.
That value may change, but the lion always
has an age attribute.

In addition to basic attributes, an abstraction

describes a concept’s basic behaviours. A
lion may have behaviours such as hunting,
eating, and sleeping. These are also
responsibilities that the lion abstraction does for its purpose of
living.

An abstraction, as explained above, should only convey a concept’s

essential attributes and behaviours. Context helps determine what is
relevant. For example, when considering the lion in a hunting
setting, it is irrelevant to consider what position the lion prefers to
sleep in. If context changes, the right abstraction may change as
well.

Object-Oriented Design | 30