Best practice is to form the conceptual design before moving on to

the technical design. The clearer the conceptual design, the better
the technical design, and the more likely your software will be built
right.

Technical Design

Technical designs build on conceptual designs and requirements to

define the technical details of the solution. In the conceptual design,
the major components and connections as well as their associated
responsibilities of the software being developed are outlined. The
technical design brings this information to the next stage—it aims to
describe how these responsibilities are met. The technical design is
not finished until each component has been refined to be specific
enough to be designed in detail.

In order to accomplish this, technical designs begin by splitting

components into smaller and smaller components that are specific
enough to be designed in detail. By breaking down components
more and more into further components, each with specific
responsibilities, you get down to a level where you can do a
detailed design of a particular component. The final result is that
each component will have their technical details specified.

In order to communicate technical design, technical diagrams are

used. Technical diagrams visualize how to address specific issues
for each component, as conceptual mock-ups are generally not
specific enough to capture this information. There are many
different technical diagrams that can be used to describe the
structure and behaviour of components, which will be addressed
later on in this specialization. Technical diagrams therefore help co-
ordinate development work.

To continue with the architectural example used throughout this

lesson, imagine having to design a kitchen. A kitchen is a
component of a house on its own, but it will require further smaller
components, such as flooring. The technical design may indicate
that the flooring will need to be made of a material that is easy to
clean, particularly if the client plans on doing a lot of cooking—
cooking can be a messy business!

Object-Oriented Design | 11
Compromise in Requirements and Design

When in the design phase, there may need to be compromises in

creating an acceptable solution. Constant communication and
feedback is key to creating the right solution that meets client needs
and works within any restrictions that may exist.

Drawing on the architectural example used throughout this lesson,

imagine the client would like an open kitchen in their house that has
no obstructions between it and the dining room. But what if a post
and beam is needed in that area to support the second floor of the
house? The homeowner and the project will need to work out a
compromise in that situation.

Designs will need to be reworked if components, connections, and

the responsibilities of the conceptual design prove impossible to
achieve in the technical design, or if they fail to meet requirements.
It is important to continually check with clients that conceptual
mock-ups capture what they want. It is easier to re-design in the
planning stages, than once coding has started.

Larger systems generally require more design time. There are more
components, connections, and responsibilities to keep track of in
larger systems. And as these components themselves are large,
they may need to be refined down to smaller components before
their design can be detailed.

Once a feasible design has been agreed upon, the technical

diagrams become the basis for constructing the intended solution.
Components at this stage may be refined enough to become
collections of functions, classes, or other components. These pieces
become a more manageable problem that developers can
individually implement.

There are many design techniques that may be used to get the most
out of the design process. The rest of this specialization will examine
those techniques.

Object-Oriented Design | 12
Design for Quality Attributes

When developing software, it is important to take a broad view on

how to achieve the desired requirements. This lesson examines how
competing ideals, roles and perspectives, potential trade-offs, and
project realities need to be taken into account and balanced in
software design.

Trade-offs

This course has reviewed the importance of requirements and

design in creating software. Sometimes, there are restrictions on
design that require compromise. Besides software requirements
based on desired functionality, there are also quality attributes to
define how well this functionality must work. But your decisions may
also involve trade-offs in different quality attributes, such as
performance, convenience, and security, and these attributes need
to be balanced.

For example, it is important to consider how quality attributes can

compete in a proposed solution under different situations. Then,
taking this into account and weighing it against the requirements of
the product, a suitable compromise can be determined. This
balancing act is an ongoing constant for software architecture.
Software architects must find the best balance between quality
attributes—often by evaluating which one is more important.
Deadlines can also influence what is feasible to do within a certain
time frame.

Let’s consider, for example, designing a front door to a house.

Security is a quality attribute that might be important, but if you add
too many locks to the door, it may be difficult to open easily and will
become inconvenient to use. A good design should balance
security with convenience and performance.

Object-Oriented Design | 13
Context and Consequences

Context provides important information when deciding on the

balance of qualities in design. For example, software that stores
personal information, which the public can access, may have
different security requirements than software that is only used by
corporate employees. In order to establish context, it is important to
talk to stakeholders.

Software design also must consider the consequences. Sometimes,

choices made in software design have unintended consequences.
For example, an idea that seems to work fine for a small amount of
data may be impractical for large amounts of data.

A good practice is to seek other perspectives on technical designs

for a more well-rounded implementation. This can be done by
asking other developers for their opinion, or by having a design
review session. It is also good practice to test a system carefully
before fully implementing a system. During the design process, you
might consider prototyping alternative ideas and running tests to
see what works best. Tests can help catch unintended
consequences. For example, testing with both small and large
amounts of data in the above example might reveal the system
limitations.

Satisfying Qualities

Qualities are achieved through satisfying functional and non-

functional requirements, which in turn are the basis for the design
process.

Functional requirements describe what the system or application is

expected to do. A key quality to achieve by satisfying a functional
requirement is that of correctness. For example, if you are designing
a music app, the app must be able to download and play a song.
The design needs to be able to outline a solution that correctly
meets this requirement.

Object-Oriented Design | 14
Non-functional requirements specify how well the system or
application does what it does. Non-functional requirements to
satisfy might include performance, resource usage, and efficiency;
these requirements can be measured from the running software.
For example, the music app may have non-functional requirements
to download music only to a certain memory limit. Other qualities
that software often satisfies in non-functional requirements include
reusability, flexibility, and maintainability. This helps inform how
well the code of software can evolve and allow for future changes.

Requirements are often incomplete at first, but are resolved with

further interactions with clients and end users.

Instructor’s Note:
If you are interested in learning more about functional and
non-functional requirements, see the requirements course of
the Coursera specialization offered by the University of Alberta
on Software Product Management.

Functional and non-functional requirements are important to satisfy,

but there may be important constraints and limitations that will lead
to compromises. For this reason, it is important to communicate and
determine what is acceptable to stakeholders. Consider this
example: all cars meet the functional requirement of providing
transportation; however, non-functional requirements and the
emphasis on certain qualities can vastly change the final product—
different accelerations, handling, weight, and fuel economy can
make the difference between a minivan and a sports car.

Reviews and tests should also be used to verify that required

qualities on design and software implementation are satisfied.
Some qualities may also be validated with feedback from end users.

Instructor’s Note:
If you are interested in learning more about reviews, see the
reviews course of the Coursera specialization offered by the
University of Alberta on Software Product Management.

Object-Oriented Design | 15
Compromise

In addition to balancing qualities and meeting functional

requirements when designing software, it is important to consider
multiple perspectives. Software must satisfy qualities that matter to
users as well as developers. In other words, how the software
structure is organized may affect the quality of performance, as
understood by users, and the qualities of reusability and
maintainability, as understood by developers.

Below are some common trade-offs in qualities for software design:

• Performance and maintainability – High performance code

may be less clear and less modular, making it harder to
maintain. Alternately, extra code for backward compatibility
may affect both performance and maintainability.
• Performance and security – Extra overhead for high security
may lessen performance.

Balance between qualities must be understood and taken into

account during design. It is important to prioritize and understand
what qualities are needed. A good question to ask to help you
determine what compromises can be made is: Is there a way to cut
back on a certain quality to balance another?

DID YOU KNOW?

Some common qualities to take into account in software design

include: performance, maintainability, security, and backwards
compatibility.

It is also important to consider the constraints by project realities on

your project. To develop the product, qualities must be balanced
with resources available such as cost, time, and manpower.

Object-Oriented Design | 16
Class Responsibility Collaborator

So far, this module has reviewed the process of eliciting

requirements and using conceptual design to gather initial thoughts
on how to satisfy those requirements in software development.
Components, connections, and responsibilities for some
requirements are established during this stage.

This module has also examined how components and connections

are refined through the technical design process, and by taking
quality attributes into account, in order to establish technical details.
This allows components and connections to be more easily
implemented.

This next lesson presents an important technique to help represent

the components, responsibilities, and connections at a high level
when forming the conceptual design. This technique is the use of
Class, Responsibility, Collaborator (CRC) cards. CRC cards help
record and organize components into classes, identify component
responsibilities, and determine how they collaborate with each
other. Therefore, they also help refine the components in your
software design.

CRC Cards

During the process of conceptual design, it is helpful not only to

identify components, responsibilities, and connections but also to
represent them. One technique is to use Class, Responsibility,
Collaborator (CRC) cards.

CRC cards are used to record, organize, and refine the components
of system design. They can be compared to note cards, which are
used to organize talking points. CRC cards are designed with three
sections: the class name at the top of the card, the responsibilities
of the class on the left side of the card, and the collaborators on
the right side of the card. See the image below for an example of
what a CRC card might look like, about the size of a physical index
card.

Object-Oriented Design | 17
 Class Name

Responsibilities Collaborators

To keep track of each candidate component and its responsibilities

using a CRC card, you place a component’s name in the class name
section, and the responsibilities in the responsibilities section.
Connections are captured in the collaborators section. Connections
or collaborators indicate other classes that the class at the top of the
card interacts with to fulfill its responsibilities. These steps are
repeated iteratively and new cards are created until all the classes,
responsibilities, and collaborators are identified for a system.

In system design, CRC cards has a purpose—it forces designers to

keep breaking components down into smaller components and
classes that can be individually described on a card.

Prototyping and Simulation

The use of CRC cards is a simple system that has many advantages.
They are cheap, editable, and widely available. They help sort
information into manageable pieces.

A key advantage of using CRC cards is that they allow you to

physically reorganize your design. As each of the components are
represented by a card, you can move related cards together, or
situate cards to suggest relationships. This allows you to
theoretically explore how your system will work and to identify any
shortcomings in the design.

You can also experiment with moving these cards around in new
orders and analyzing the resulting consequences, allowing you to
play with alterative designs. This means that CRC cards can be used
to prototype and simulate a system for conceptual design.

Object-Oriented Design | 18
When you develop designs, these are sometimes referred to as CRC
models. CRC cards should be organized by placing closely
collaborating components together. This makes it easier to
understand the relationships or connections between classes or
components.

CRC cards are excellent tools to bring to software development

team meetings. All the cards can be placed on the table, and
facilitate a discussion or a simulation with the team of how these
classes work together with other classes to achieve their
responsibilities. This allows you to both visually explain your system
and gain potential input from other parties.

CRC cards are useful tools, but they are most powerful when used
for prototyping and simulation for conceptual design. Many other
techniques have been developed to help you design more
effectively. The rest of this specialization will focus on some of these
various design techniques.

Object-Oriented Design | 19
MODULE 2: OBJECT-ORIENTED MODELLING

Upon completion of this module, you will be able to:

(a) Describe issues in creating models for design.

(b) Understand how programming languages evolved toward object
orientation.
(c) Explain the four major design principles used in object-oriented
modelling:
a. Abstraction
b. Encapsulation
c. Decomposition
d. Generalization
(d) Express the above design principles in using UML class diagrams
and Java code.
(e) Explain and express implementation inheritance.
(f) Explain and express interface inheritance.

The previous module in this course provided an introduction to the

importance of design in the software development process, and
ended with explaining the advantage of using CRC cards to
complete a conceptual design.

This module will explore object-oriented modelling even further. It

will begin by examining modelling problems and how
programming languages evolved towards object orientation. Then,
the four major design principles of abstraction, encapsulation,
decomposition, and generalization will be discussed. These
principles help in problem solving and lead to developing software
that is flexible, reusable, and maintainable. They are key principles
to follow for developing a good design for your software.

This module will also explore how to express design structure in

Java code and UML class diagrams using the principles of
abstraction, encapsulation, and decomposition. Finally, it will
discuss implementation and interface inheritance within the design
principle of generalization.

Object-Oriented Design | 20