9/25/2022

Faculty of Engineering & IT

Software Engineering Department

ITSE4306 – Software
Design
Dr Ghassan Abu Samhadana &
Dr Khaled Ismail

Software Design: Definition

• Software design is an iterative process through which
requirements are translated into a “blueprint” for
Constructing the software.

• A blueprint is a reproduction of a technical drawing, documenting an

architecture or an engineering design

• Initially, the blueprint depicts a holistic view of software.

1
 9/25/2022

Process of Design Engineering

• During the design process the software specifications are
transformed into design models
• Models describe the details of the data structures, system
architecture, interface, and components.
• Each design product is reviewed for quality before moving to the next
phase of software development.
• At the end of the design process a design model and specification
document is produced.
• This document is composed of the design models that describe the
data, architecture, interfaces and components.

Object-Oriented Thinking
Object-oriented thinking involves:
1) examining the problems or concepts at hand,
2) breaking them down into component parts,
3) and thinking of those as objects.
• For example, a tweet on Twitter or a product on an online shopping website could
be considered objects.
• Objects may have specific details associated with them, which are relevant to
users.
• A person object may have details such as name, age, gender, and occupation.
• Objects might also have behaviours or responsibilities associated with them.
• A person may have associated behaviours such as sitting down or typing.
• An electronic device may be responsible to power on or off, or to display an image.

2
 9/25/2022

The Benefits of using objects to represent things in your code:

▪ Objects keep code organized by putting related details and specific functions in
distinct, easy-to-find places.
▪ Objects keep code flexible, so details can be easily changed in a modular way within
the object, without affecting the rest of the code.
▪ Objects allow code to be reused, as they reduce the amount of code that needs to be
created, and keeps programs simple.
▪ A good practice to thinking about the world around you in terms of objects, and the
attributes those objects might have.

Design in the Software Process

▪ Development process is generally iterative and these iterations consist of
• Taking a set of requirements based on the identified problem(s) and using them to
create conceptual design mock-ups and technical design diagrams,
• Then it can be used to create a working software implementation, which must also
pass testing.
• This process is repeated for each set of requirements, eventually creating a
complete solution for the project.
• Many projects fail when this process is skipped over, especially when work
immediately begins with coding, and there is a lack of understanding of the
requirements and design.
• Requirements and design activities help you to understand what assumptions you
need so that you create the right product.

3
 9/25/2022

Requirements
• Requirements are conditions or capabilities that must be implemented in a
product, based on client or user request.
• Eliciting requirements involves actively probing the client vision, clarifying what
may not have been told, and asking questions about issues the client may not have
even considered.
• It is also important to establish potential trade-offs the client may need to make in
the solution.
• For example, a client may decide to sacrifice a feature in order to ensure that a
program runs faster, if speed is an important need.
• Once requirements and trade-offs are established, they may serve as the
foundation for design.
• To better understand requirements, imagine you are an architect building a house.

Design
• When the initial set of requirements has been created, the next step in the process
is to produce a conceptual design and a technical design.
• Conceptual designs are created with an initial set of requirements as a basis.
• The conceptual design recognizes appropriate components, connections, and
responsibilities of the software product.
• Conceptual designs outline the more high-level concepts of your final software
product.
• Conceptual designs are expressed or communicated through conceptual mock-
ups.
• These are visual notations that provide initial thoughts for how requirements will be
satisfied.
• Mock-ups for software involving user interfaces are often presented as
wireframes, which are a kind of blueprint or basic visual representation of the
product.

4
 9/25/2022

Design
• Conceptual mock-ups help to clarify design decisions with clients and users by
providing a simple way to illustrate and discuss how a product will work.
• Mock-ups illustrate major components and connections, or relations
between the components.
• Once you start to create a mock-up, you may more easily see what
components are missing or may not work.
• These flaws would require further clarification with your client or involve
additional conceptual design work.
• Every component also has a task it needs to perform. This is known as its
responsibility.
• Mock-ups do not outline technical details, because that falls outside the
scope of conceptual design.

• 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.
• Technical designs begin by splitting components into smaller and smaller
components that are specific enough to be designed in detail.
• By breaking down 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.

5
 9/25/2022

Technical Design
• 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.
• 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!

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.
• 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 easier to re-design in the planning stages, than once coding has started.
• 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.

6
 9/25/2022

Design for Quality Attributes

Trade-offs:
• 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.
• 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.
• 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.

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.
• During the design process, you might consider prototyping alternative ideas and
running tests to see what works best.
• For example, testing with both small and large amounts of data in the above example
might reveal the system limitations.

7
 9/25/2022

Satisfying Qualities
• Qualities are achieved through satisfying functional and nonfunctional
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.
• 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.

Satisfying Qualities
• 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.
• 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.
• Software must satisfy qualities that matter to users as well as developers.
• 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.

8
 9/25/2022

Satisfying Qualities
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.
• 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?
• To develop the product, qualities must be balanced with resources available such
as cost, time, and manpower.

Class Responsibility Collaborator

• During the process of conceptual design, it is helpful not only to identify
components, responsibilities, and connections but also to represent them.
• Class, Responsibility, Collaborator (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 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.
• Connections or collaborators indicate other classes that
the class at the top of the card interacts with to fulfill
its responsibilities.
• In system design, CRC cards forces designers to keep
breaking components down into smaller components
and classes that can be individually described on a card.

9
 9/25/2022

OBJECT-ORIENTED MODELLING

Design Specification Models

Data Object Description Process Specification (PSPEC)

Entity-
Relationship
Data Flow Procedural
Diagram
Diagram Design
Interface
Data Dictionary
Design

Architectural
State-Transition
Diagram
Design

Control Specification (CSPEC)

Data Design

THE ANALYSIS MODEL THE DESIGN MODEL

10
 9/25/2022

Data Design
• Created by transforming the analysis information model (data dictionary and
ERD) into data structures required to implement the software.
• Part of the data design may occur in conjunction with the design of software
architecture.
• More detailed data design occurs as each software component is designed.

Data
Dictionary

Data Design

Entity Relationship
Diagram

11
 9/25/2022

Architectural Design
Defines:
• The relationships among the major structural
elements of the software
• The “design patterns” than can be used to
achieve the requirements that have been
defined for the system
• The constraints that affect the way in which
the architectural patterns can be applied.
• It is derived from the system
• specification, the analysis model, and the
subsystem interactions defined in the
analysis model (DFD). Dataflow Diagram

Architectural Design

MVP Design Pattern

12
 9/25/2022

Interface Design
• Describes how the software
elements communicate with each
other, with other systems and with
human users

• Much of the necessary information

required is provided by the data flow
and control flow diagrams

Control Flow Diagram

Procedural/Component-level Design
• Created by transforming the structural elements defined by the software
architecture into procedural descriptions of software components.
• Uses information obtained from :
• Process specification (PSPEC)
• Use cases, FlowCharts, Activity Diagrams…
• Control specification (CSPEC)
• State Transition Diagram (STD), Decision tables …

State Transition Diagram

13
 9/25/2022

Creating Models in Design

• The design should present and describe concepts in a way that users and
developers both understand, so they may discuss using common terms.
• 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.

Creating Models in Design

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

14
 9/25/2022

Abstraction
• Abstraction breaks a concept down into a simplified description that ignores
unimportant details and emphasizes the essentials needed for the concept, within
some context.
• Essential attributes and behaviours should be captured with no surprises and no
definitions that fall beyond its scope.
• 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.
• Designer choose the most appropriate abstraction to the context of the software
development, and the context must be understood before creating an abstraction.

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.
▪ 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.
▪ Abstraction helps to simplify class designs, so they are more focused,
and understandable to someone else viewing them.
▪ If the purpose of the system being built, or if the problem being
solved changes, it is important to re-examine your abstractions and
change them accordingly.

15
 9/25/2022

Encapsulation
• This principle involves a concept that allows something to be contained in a
capsule, some of which you can access from the outside and some of which you
cannot.
• There are three ideas behind encapsulation. These are:
• The ability to “bundle” attribute values (or data) and behaviours (or functions) that
manipulate those values, into a self-contained object.
• The ability to “expose” certain data and functions of that object, which can be
accessed from other objects, usually through an interface.
• The ability to “restrict” access to certain data and functions to only within the object.
• The principle of abstraction helps determine what attributes and behaviours are
relevant about a concept in a determined context.
• Encapsulation keeps software modular and easy to work with.
• Classes are easy to manage, as their internal behaviour is not relevant to other
classes, as long as they can interface together.

Decomposition
• It consists of taking a whole thing, and dividing it into different parts.
• Alternately, decomposition can also indicate taking separate parts with different
functionalities and combining them to create a whole.
• Decomposition allows problems to broken into smaller pieces that are easier to
understand and solve.
• The general rule for decomposition is to look at the different responsibilities of a
whole and evaluate how the whole can be separated into parts that each have a
specific responsibility.
• Each of these parts are in fact separate objects that can be created from separate
classes in your design.
• In this way, decomposition is similar to abstraction where you are dividing a whole
into objects with essential characteristics.

16
 9/25/2022

Generalization
• Generalization helps reduce redundancy when solving problems.
• In coding, algorithmic behaviours are often modelled through methods.
• A method allows a programmer to generalize a behaviour, so the behavior can be
applied to different input data.
• This generality reduces the need to have identical code throughout a program.
• Object-oriented modelling achieves generalization by classes through inheritance.
• In generalization we take repeated, common, or shared characteristics between
two or more classes and factor them out into another class.
• Both methods and inheritance exemplify the generalization design principle
through the D.R.Y. or “Don’t Repeat Yourself” rule.

Abstraction Example
• Abstraction can be applied at the design level using UML class diagrams. The
design is eventually turned into code.
• CRC cards capture components in systems design. Components can eventually be
refined into functions, classes, or collections of other components.
An example of a CRC card, as abstracted for a food item
in the context of a grocery store.

17
 9/25/2022

Abstraction Example
• Every concept or class in a class diagram is represented with a box.

• The class name is the same as the class name in your ▪ In the example above, food objects have a
Java class. method to return if it is on sale or not. This
• The properties section is equivalent to Java’s member method has been named “isOnSale”.
variables. ▪ The method will return a boolean to represent if
it is on sale. A Boolean value is either true or
• Variable types can be classes or primitive types.
<variable name>:<variable type> false. The isOnSale operation takes no parameter,
so no parameter list is included.
• The operations section is equivalent to Java’s methods. This
▪ If you were to add a parameter to the operation,
section defines the behaviours of the abstraction.
<name>( <parameter list> ) : <return type> such as a date in this case, the parameter would
follow the same template as the class diagram’s
properties. The final section would read:
isOnSale(date: Date) : Boolean

Abstraction Example
• Class diagrams distinguish a difference between responsibilities that become
properties and responsibilities that become operations, whereas CRC cards list
them together.
• Helping distinguish this ambiguity makes class diagrams easier to translate into
code for a programmer.
• we can see how easy it is to turn a class diagram into a class in Java.
• It is possible to use this mapping in reverse to turn code into class diagrams.
public class Food {
public String groceryID;
public String name;
public String manufacturer;
public Date expiryDate;
public double price;
public boolean isOnSale( Date date ) {
}
}

18
 9/25/2022

Encapsulation Example
The design principle of encapsulation involves three ideas:
• Data and functions that manipulate that data are “bundled” into a self-contained
object.
• Data and functions of the object can be exposed or made accessible from other
objects.
• Data and functions of the object can be restricted to only within the object.
• In a UML class diagram, encapsulation is expressed by having all of the object’s
relevant data defined in attributes of the class, and by providing specific methods
to access those attributes.
• UML class diagrams can express encapsulation. The class diagram itself already
bundles data and functions in a self-contained object.
• However, access and restriction (two aspects of visibility) can be represented as
well, through the use of symbols – and +.

Encapsulation Example
Example of a UML class diagram for a student.

• The minus sign indicates that a method or attribute is private and can only be accessed from within
the class.
• The plus sign indicates that a method can be accessed publicly. In this case, the public methods can be
used to manipulate the student’s GPA.
• Encapsulation in UML class diagrams helps you determine the “gate” to controlling data, by using only public
methods to access the data attributes of the class.

19
 9/25/2022

Decomposition
• The design principle of decomposition takes a whole thing and divides it into
different parts.
• It also does the reverse, and takes separate parts with different
functionalities, and combines them to form a whole.
• There are three types of relationships in decomposition, which define the
interaction between the whole and the parts:
▪ Association
▪ Aggregation
▪ Composition

Association
• Association indicates a loose relationship between two objects, which may interact
with each other for some time.
• They are not dependent on each other—if one object is destroyed, the other can
continue to exist, and there can be any number of each item in the relationship.
• One object does not belong to another, and they may have numbers that are not
tied to each other.
• An example of an association relationship could be a person and a hotel.
• A person might interact with a hotel but not own one. A hotel may interact with
many people.

20
 9/25/2022

Association
• Association is represented in UML diagrams as below:

• The straight line between the two UML objects denote that there is a relationship
between the two UML objects of person and hotel, and that relationship is an
association.
• The “zero dot dot star” (0…*) on the right side of the line shows that a Person
object is associated with zero or more Hotel objects, while the “zero dot dot star”
on the left side of the line shows that a Hotel object is associated with zero or
more Person objects.

Association
• Association can be represented in Java code as well.

public class Student {

public void play( Sport sport ){
execute.play( sport );
}
}

• In this code excerpt, a student is passed a sport object to play, but the student
does not possess the sport. It only interacts with it to play.
• The two objects are completely separate, but have a loose relationship.
• Any number of sports can be played by a student and any number of students can
play a sport.

21
 9/25/2022

Aggregation
• Aggregation is a “has-a” relationship where a whole has parts that belong to it.
Parts may be shared among wholes in this relationship.
• Aggregation relationships are typically weak, however. This means that although
parts can belong to wholes, they can also exist independently.
• An example of an aggregate relationship is that of an airliner and its crew.
• The airliner would not be able to offer services without the crew. However, the
airliner does not cease to exist if the crew leave. The crew also do not cease to
exist if they are not in the airliner.
• Aggregation can be represented in UML class diagrams with the symbol of an
empty diamond as below:

Aggregation

• In this diagram, a straight line is used again to symbolize a relationship between the
Airliner object, and the Crew Member object.
• In this case, the “zero dot dot star” on the right side of the line indicates that a Airliner
object might have zero or more crew members.
• The “zero dot dot star” on the left side of the line indicates that a Crew Member object
can be had by zero or more
• Airliner objects. The empty diamond indicates which object is considered the whole
and not the part in the relationship.

22
 9/25/2022

Aggregation
• Aggregation can be represented in Java code as well.

public class Airliner {

private ArrayList<CrewMember> crew;
public Airliner() {
crew = new ArrayList<CrewMember>();
}
public void add( CrewMember crewMember ) {
}
}
• In the Airliner class, there is a list of crew members.
• The list of crew members is initialized to be empty and a public method allows
new crew members to be added. An airliner has a crew.

Composition
• Composition is one of the most dependent of the decomposition relationships.
• This relationship is an exclusive containment of parts, otherwise known as a strong
“has-a” relationship.
• In other words, a whole cannot exist without its parts, and if the whole is
destroyed, then the parts are destroyed too.
• In this relationship, you can typically only access the parts through its whole.
Contained parts are exclusive to the whole.
• An example of a composition relationship is between a house and a room. A house
is made up of multiple rooms, but if you remove the house, the room no longer
exists.

23
 9/25/2022

Composition
Composition can be represented with a filled-in diamond using UML class diagrams,
as below:

• The lines between the House object and the Room object indicates a relationship
between the two.
• The filled-in diamond next to the House object means that the house is the whole in
the relationship.
• If the diamond is filled-in, it symbolizes that the “has-a” relationship is strong.
• The two objects would cease to exist without each other.
• The one “dot dot star” indicates that there must be one or more Room objects for
the House object.

Composition
• Composition can be represented using Java code as well.

public class House {

private Room room;
public House(){
room = new Room();
}
}

• In this example, a Room object is created at the same time that the House object
is, by instantiating the Room class.
• This Room object does not need to be created elsewhere, and it does not need to
be passed in when creating the House object.
• The two parts are tightly dependent with one not being able to exist without the
other.

24
 9/25/2022

Generalization
• The design principle of generalization takes repeated, common, or shared
characteristics between two or more classes and factors them out into another
class, so that code can be reused, and the characteristics can be inherited by
subclasses.

Generalization
• It is possible to translate UML class diagrams into code.

• You may also notice the use of a # symbol. This

symbolizes that the Animal’s attributes are protected.
• Protected attributes in Java can only be accessed by:
✓ the encapsulated class itself
✓ all subclasses
✓ all classes within the same package

25
 9/25/2022

OTHER DESIGN PRINCIPLES

Evaluating Design Complexity

• It is important to keep modules simple when you are programming.
• If your design complexity exceeds what developers can mentally handle, then bugs
will occur more often.
• This lesson will use the term module to refer to program units containing classes
and the methods within them.
• A system is a combination of various modules.
▪ If the system has a bad design, then modules can only connect to other specific
modules and nothing else.
• A good design allows any modules to connect together without much trouble.
• In other words, in a good design, modules are compatible with one another and
can therefore be easily connected and re-used.
• The metrics often used to evaluate design complexity are coupling and cohesion.

26
 9/25/2022

Coupling
• Coupling focuses on complexity between a module and other modules.
• Coupling can be balanced between two extremes: tight coupling and loose
coupling.
• If a module is too reliant on other modules, then it is “tightly coupled” to others.
This is a bad design.
• If a module finds it easy to connect to other modules through well-defined
interfaces, it is “loosely coupled” to others. This is good design.
• In order to evaluate the coupling of a module, the metrics to consider are: degree,
ease, and flexibility.
• Degree is the number of connections between the module and others. The degree
should be small for coupling.
• For example, a module should connect to others through only a few parameters or
narrow interfaces. This would be a small degree, and coupling would be loose.

Coupling
• Ease is how obvious are the connections between the module and others.
• Connections should be easy to make without needing to understand the
implementations of other modules, for coupling purposes.
• Flexibility indicates how interchangeable the other modules are for this module.
• Other modules should be easily replaceable for something better in the future, for
coupling purposes.
Signs that a system is tightly coupled and has a bad design are:
• a module connects to other modules through a great number of parameters or
interfaces
• corresponding modules to a module are difficult to find
• a module can only be connected to specific other modules and cannot be
interchanged

27
 9/25/2022

Cohesion
• Cohesion focuses on complexity within a module, and represents the clarity
of the responsibilities of a module.
• Like complexity, cohesion can work between two extremes: high cohesion
and low cohesion.
• A module that performs one task and nothing else, or that has a clear
purpose, has high cohesion. A good design has high cohesion.
• If a module encapsulates more than one purpose, if an encapsulation has to
be broken to understand a method, or if the module has an unclear purpose,
it has low cohesion. A bad design has low cohesion.
• If a module has more than one responsibility, it is a good idea to split the
module.

Coupling and Cohesion

• It is important to balance between low coupling and high cohesion in system
design.
• Both are necessary for a good design.
• However, in complex systems, complexity can be distributed between the
modules or within the modules.
• For example, as modules are simplified to achieve high cohesion, they may
need to depend more on other modules, thus increasing coupling.
• On the other hand, as connections between modules are simplified to achieve
low coupling, the modules may need to take on more responsibilities, thus
lowering cohesion.

28
 9/25/2022

Separation of Concerns
• Decomposition divides a whole into different parts.
• To understand why decomposition is necessary in design, the principle of
separation of concerns must be examined.
• Separation of concerns is about keeping the different concerns in your design
separate.
• When software is designed, different concerns should be addressed in different
portions of the software.
Separation of concerns provides many advantages:
▪ They allow you to develop and update sections of the software independently.
▪ you do not need to know how all sections of code work in order to update a section.
▪ allows changes to be made to one component without requiring a change in another.

Separation of Concerns
• When addressing concerns separately, more cohesive classes are created and the
design principles of abstraction, encapsulation, decomposition, and generalization
are enforced:
• Abstraction occurs as each concept in the problem space is separated with its own
relevant attributes and behaviours.
• Encapsulation occurs as the attributes and behaviours are gathered together into
their own section of code called a class.
Access to the class from the rest of the system and its implementation are separated,
so details of implementation can change while the view through an interface can stay
the.
• Decomposition occurs as a whole class can be separated into multiple classes.
• Generalization occurs as commonalities are recognized, and subsequently separated
and generalized into a superclass.

29
 9/25/2022

Separation of Concerns
• Using separation of concerns in software design creates a system that is
easier to maintain.
• Because each class is organized so that the class only contains the code that it needs to
do its job.
• Modularity is increased in turn, which allows developers to reuse and build up
individual classes without affecting others.
• It is important to note that the boundaries of each class will not always be obvious
in practice.
• Deciding how to abstract, encapsulate, decompose, and generalize to address the
many concerns for a given problem is at the core of designing modular software.

Separation of Concerns Example

• Smartphones are capable of many behaviours: taking photos, scheduling meetings, sending
and receiving email, browsing the Internet, sending texts, and making phone calls.
• This example will only focus on two functions, for the sake of simplicity: the use of a camera
and traditional phone functions.
❑ This code has a SmartPhone class with attributes called camera public class SmartPhone {
and phone, and associated behaviours. private byte camera;
❑ This system has low cohesion, as there are behaviours that are private byte phone;
public SmartPhone() { … }
not related to each other.
public void takePhoto() { … }
❑ The camera behaviours do not need to be encapsulated with
public void savePhoto() { … }
the phone behaviours in order for the camera to do its job. public void cameraFlash() { … }
❑ The components also do not offer modularity. public void makePhoneCall() { … }
o For example, it is not possible to access the camera or the public void encryptOutgoingSound() { … }
phone separately if another system is built that requires only public void decipherIncomingSound() { … }
one or the other. }
oThe camera also would not be able to be replaced with a
different camera, or even a different object, without
removing the code for the camera completely from this class.

30
 9/25/2022

Separation of Concerns Example

• The SmartPhone class needs to be more cohesive, and each component of the
smartphone should have distinctive functionality.
• Using the separation of concerns, we can identify that the SmartPhone class has
two concerns:
1. To act as a traditional telephone.
2. To take pictures using the built-in camera.
• With the concerns identified, it is possible to separate them into their own more
cohesive classes and encapsulate all the details about each concern into
functionally distinct and independent classes.
• The SmartPhone class will reference instances of the new classes so that the
smartphone can act as a coordinator of the camera and the phone.
• This will let our smartphone provide access to all the behaviours of the camera
and the phone, without having to know how each component behaves.

Separation of Concerns Example

• Using a UML Class diagram, this is how the new design for the SmartPhone system might look:

• The attributes and behaviours

for the phone and camera have
been separated into two distinct
interfaces.
• These are each implemented
with a corresponding class.

31
 9/25/2022

Separation of Concerns Example

• The code would translate as below:
public interface ICamera { public class SmartPhone {
public void takePhoto(); private ICamera myCamera;
public void savePhoto(); private IPhone myPhone;
public void cameraFlash(); public SmartPhone( ICamera aCamera,
} IPhone
public interface IPhone { aPhone ) {
public void makePhoneCall(); this.myCamera = aCamera;
public void encryptOutgoingSound(); this.myPhone = aPhone;
public void deciphereIncomingSound(); }
} public void useCamera() {
public class FirstGenCamera implements return this.myCamera.takePhoto();
ICamera { }
/* Abstracted camera attributes */ public void usePhone() {
public class TraditionalPhone return this.myPhone.makePhoneCall();
implements IPhone { }
/* Abstracted phone attributes */ }
}

• In the previous example, separation of concerns was used by:

• Separating out the notions of camera and phone through generalization and
defining the two interfaces.

• Separating out the functionality for a first-generation camera and traditional

phone by applying abstraction and encapsulation, and defining two
implementing classes.

• Applying decomposition to the smartphone so the constituent parts are

separated from the whole.

32
 9/25/2022

Conceptual Integrity
• Conceptual integrity is a concept related to creating consistent software.
• Conceptual integrity entails making decisions about the design and
implementation of a software system,
• so even if multiple people work on it, it would seem cohesive and consistent as if only
one mind was guiding the work.
There are multiple ways to achieve conceptual integrity. These include:
❑ communication
❑ code reviews
❑ using certain design principles and programming constructs
❑ having a well-defined design or architecture underlying the software
❑ unifying concepts
❑ having a small core group that accepts each commit to the code base.
• Practicing conceptual integrity helps guide the software development team by
making the design and logic of the software consistent and easy to follow for any
team member.

▪ Effective communication maintains conceptual integrity and allows team members to discuss and agree to use
certain libraries or methods when addressing certain issues. This in turn helps create more consistent code.
▪ Some good practices to foster communication include agile development practices like daily stand-up meetings
and sprint retrospectives.
▪ Code reviews are systematic examinations of written code. Developers go through code line by line and
uncover issues in each other’s code.
▪ This helps identify mistakes in the software, but it also helps create consistency among different developers’
code.
▪ Using certain design principles and programming constructs helps maintain conceptual integrity.
▪ Java interfaces are a construct that can accomplish this. [also, design patterns]
▪ While software design is typically associated with guiding the internal design of software running as a single
process, software architecture describes how software running as multiple processes work together and how
they relate to each other. This helps create consistency.
▪ Unifying concepts involves taking different concepts and finding a commonality, so that each concept can be
seen and treated in similar ways. For example, in the Unix, every resource can be seen and manipulated as if it
were a file.
▪ Having a small core group that accepts each commit to the code base. This is similar to exercising code reviews,
but it restricts the review to only core members of the software team. These members are responsible for
ensuring that any software changes follow the overall architecture and design of the software.

33
 9/25/2022

Generalization Principles
• Generalization and inheritance are some of the more difficult topics to master in
object-oriented programming and modelling.
• Inheritance is a powerful design tool that can help create clean, reusable, and
maintainable software systems.
• However, its misuse can lead to poor code. If design principles are used improperly,
they may create more problems than they solve.

To identify if inheritance is being misused, keep a couple of generalization principles in mind.

• One principle can be formulated as a question to ask yourself about whether a subclass
should exist:
“Am I using inheritance to simply share attributes or behaviour without further adding
anything special in my subclasses?”
• If the answer to this question is “yes,” then inheritance is being misused, as there is no
point for the subclasses to exist. The superclass should already be enough.

Generalization Principles
• For example, an employee is a general type for managers, salespeople, and cashiers,
but each of those subtypes of employee perform specific functions. Inheritance
makes sense in this case.
• However, if you are creating different kinds of pizza, there is no true specialization
between different kinds of pizza, so subclasses are unnecessary.
• Another technique is determining if the Liskov substitution principle is broken.
• The principle states that a subclass can replace a superclass, if and only if, the subclass
does not change the functionality of the superclass.
• This means that if a subclass replaces a superclass, but replaces all the superclass
behaviours with something totally different, then inheritance is being misused.
• For example, if a Whale class which exhibits swimming behaviour is substituted for an
Animal class, then functions such as running and walking will be overridden.
• The Whale no longer behaves in the way we would expect its superclass to behave,
violating the Liskov substitution principle.

34
 9/25/2022

• In cases where inheritance is not appropriate, decomposition may be the solution.

UML Sequence Diagrams

• They are a type of UML diagram, commonly used as a planning tool before the
development team starts programming.
• Sequence diagrams are used to show a design team how objects in a program interact with
each other to complete tasks.
• Sequence diagrams are a useful technique to help create clean, well- designed programs.
• In simple terms, a sequence diagram is like a map
of conversations between different people, with
the messages sent from person to person
outlined.
• Sequence diagrams can help you visualize the
classes you will create in your software and
determine the functions that will need to be
written.
• It may also illustrate problems in your system
that were previously unknown.

35
 9/25/2022

UML Sequence Diagrams

Let us examine each component of a sequence diagram.
• Boxes are used to represent a role played by an object. The role is typically named after the
class for the object.
• “Lifelines,” which are vertical dotted lines, are used in the diagram to indicate an object as
time goes by.
• Solid line arrows are used to show messages that are sent from one object to another, or a
sender to a receiver.
• Receivers are at the pointed end of an arrow. A short description of the message is usually
included above the arrow.
• Dotted line arrows are used to show a return of data and control back to initiating objects.
A short description of the return of data or control is usually included above the arrow.
• Small rectangles along an object’s lifeline denote a method activation. You activate an
object whenever an object sends, receives, or is waiting for a message.
• People, or actors, may also be included in sequence diagrams if they use or interact with
objects. Actors are typically represented with stick figures.

UML Sequence Diagrams

• Sequence diagrams are typically framed within a large box. Titles for the diagram are
indicated in top, left corners.
• It is good practice to provide a meaningful title, as the diagram will be referenced for
development.
• Another good practice is to draw objects from left to right in the sequence as they
interact with each other.
An example of a sequence diagram for changing the channel
of your television using a remote control, with all of the
elements described above.

36
 9/25/2022

A sequence diagram can contain other sequence diagrams within them.

As you design software, your sequence diagrams may get much more complicated. Loops and
alternative processes can also be demonstrated in a sequence diagram.
An alternative process is a sequence of actions that will occur if a condition is true. An
alternative sequence can be placed in a box and labelled “alt” for alternative in the top right
corner.
❑ Imagine a scenario where the TV viewer is unsure what
channel to go to and would like to surf channels until they
pick one they like.
❑ This scenario can be illustrated under the previous
sequence with the condition “[else].”
❑ This indicates that this scenario occurs only if all the other
alternatives are false.
❑ This scenario also contains a loop. This can be illustrated
through adding a box labelled “loop.”
❑ Under the label, the conditional statement for the loop
should be written.
❑ If that statement is true, then the system will go through
the loop.

UML State Diagrams

• They are a technique used to describe how systems behave and respond.
• They follow the states of a system or a single object and show changes between the
states as a series of events occur in the system.
• A state diagram illustrates object behaviour by depicting the changing states of an
object. These change in response to different events.
• A state is the way an object exists at a particular point in time. The state of an object
is determined by the values of its attributes.
• A good metaphor for states is that of a car. A car with an automatic transmission might
have different states: park, reverse, neutral, and drive.
• If a car is in reverse, it can only behave by moving backwards. If you want to move forward,
you need to change the state of the car to drive.
• This is similar to states of objects in a software system.
• When an object is in a certain state, it behaves in a specific way or has attributes set to
specific values.

37
 9/25/2022

UML State Diagrams

• Let us examine the different elements of state diagrams:
• A filled circle indicates the starting state of the object.
• Every state diagram begins with a filled circle.
• Rounded rectangles indicate other states.
• These rectangles have three sections: ▪ State names should be
short, meaningful titles for
a state name, state variables, and activities. the state of the object.
• Entry activities are actions that occur when the state is just Each state should have at
entered from another state. least a state name.
• Exit activities are actions that occur when the state is exited ▪ State variables are data
and moves on to another state. relevant to the state of the
• Do activities are actions that occur while the object is in a object.
certain state. ▪ Activities are actions that
• Arrows indicate transitions from one state to another. are performed when in a
Transitions are typically triggered by an event. certain state. There are
• This event is generally described above the arrow. three types of activities
present for each state:
A circle with a filled circle inside indicates termination. Entry, Exit, and Do
Termination represents an object being destroyed or the process being completed. activities.

UML State Diagrams

• State diagrams can be useful to help determine the events that might occur during
an object’s lifetime, such as different user inputs, and how that object should
behave when these events occur, like checking conditions and performing actions.
• Sometimes it may be easier to see changes in state in a diagram, rather than
reading through source code.
• State diagrams can also help identify issues in a software system, such as discovering
a condition that was unplanned for.
• They can also help create tests—knowing the different states of a system can help
ensure that tests are complete and correct.

38
 9/25/2022

Model Checking
• Model checking is a systematic check of your system’s state model in all its possible
states.
• Model checking helps find errors that other tests cannot.
• In model checking, you check all the various states of the software to try and
identify any errors, by simulating different events that would change the states and
variables of the software.
• This will help expose any flaws by notifying you of any violation of the rules that
occur in the behaviour of the state model.
• Typically, model checks are performed by model checking software.
• There are different types of software available for such tests, some of which are free and
available for developers using different languages.
• Model checking is typically performed during testing of the software.

Model Checking
• Imagine software that has a rule not to produce a deadlock.
• Deadlock is a situation where the system cannot continue because two tasks are waiting
for the same resource.
• The model checker would simulate the different states that could occur in your
system, and if a deadlock was possible, it would provide details of this violation.
Let us go through the process for model checking software.
▪ Model checkers begin by generating a state model from your code.
• A state model is an abstract state machine that can be in one of various states.
▪ The model checker then checks that the state model conforms to be certain
behavioural properties.
• For example, the model checker can examine the state model for flaws like race conditions,
exploring all the possible states of your model.

39
 9/25/2022

Model Checking
There are three different phases in model checking:
❑The first is the modelling phase.
• During this phase, the model description is entered in the same programming
languages as the system. Any desired properties are also described.
• This phase also performs sanity checks. Sanity checks are quick checks that should be
easy to do, as they come from clear and simple logic.
• It is beneficial to test for these simple errors before using model checkers, so the focus
can be on specifying the more complex properties to check.
• Sanity checks might include something as simple as turning the system on and off.
❑The second phase is the running phase.
• The running phase is when the model checker is run to see how the model conforms to
the desired properties described in the modelling phase.

Model Checking
❑The third and final phase is the analysis phase.
• This phase is when all desired properties are checked to be satisfied, and if there are
any violations. Violations are called counterexamples.
• The model checker should provide descriptions of violations in the system, so you can
analyze how they occurred.
• Information provided by the model checker allows you to revise your software and
fix any problems.
• Once problems are fixed, it is good practice to run the model checker again.
• Repeat this process until you are sure the software is correct with respect to the
desired properties.
• Model checking helps ensure not only that software is well designed, but also that
software meets desired properties and behaviour, and it works as intended.

40
 9/25/2022

Software Architecture

Architecture Overview and Process

• Software architecture is the fundamental design of an entire software system.
• It defines what elements are included in the system, what function each element
has, and how each element relates to one another.
• It follows that to design a software system, a software architect has to take many
factors into consideration:
▪ the purpose of the system,
▪ the audience or users of the system,
▪ the qualities that are of most importance to users, and
▪ where the system will run.
• Software architecture is important, particularly for large systems.
• If there is a clear design of the overall system from the start, there is a solid basis for
developers to follow.
• Each developer will then know what needs to be implemented and how things are
related to meet desired needs efficiently. This avoids conflicts, duplication, and ad
hoc unnecessary work.

41
 9/25/2022

Architecture Overview and Process

Some advantages of software architecture include:
• higher productivity for the software team, as a well-defined structure helps to
coordinate work, implement individual features, or guide discussions on potential issues
• improved evolution for the software, since design principles are applied to make
changes easier to accomplish or defects easier to find
• enhanced quality in the software by carefully considering the needs and perspectives of
all the stakeholders
• Software architecture helps make a system easier to maintain, reuse, and adapt.
• In order to develop software architecture, architects must take into account the
stakeholders of the system.
• Stakeholders are the people who have an interest in the software at hand. They either
use the system or benefit from it in some way.
• Software developers, Project Managers, Clients, and End users.
• Software architecture have the previous stakeholders. Each will have their own perspective.

Kruchten’s 4+1 View Model

• One important way software architecture is presented is through UML diagrams.
• Multiple perspectives are necessary to capture the complete behaviour and
development of a software system.
• One consideration is the functionality of the software.
▪ Functionality involves what a system does to satisfy the purpose the client desires.
▪ Focusing on this functionality and the needed objects leads to a perspective called the
logical view.
• Another consideration is how well the software executes, using characteristics like
the efficiency of the system or the interaction of subprocesses.
• These characteristics affect the performance and scalability of the system.
• Focusing on the processes implemented by the objects in the logical view leads to a
perspective called the process view.

42
 9/25/2022

Kruchten’s 4+1 View Model

• Software can also involve the development view.
• This perspective focuses on implementation considerations such as the hierarchical
structure of the software.
• The programming languages of the system will heavily influence this structure and
therefore places constraints upon development.
• Another perspective of the software can be seen through the physical view.
• The software will have physical components that interact and need to be deployed.
• The interaction between these different elements and their deployment will affect how
the system works.
• All four views share the purpose or desired capabilities of the software as defined by
the client.
• Scenarios outline use cases or tasks required by the end users, which provides
context to help to detail the four views.
• Together, logical, process, development, and physical views, along with scenarios form Philippe Kruchten’s 4+1 View
Model.

Kruchten’s 4+1 View Model

Let us examine each of these views individually.
❑ Logical View
• The logical view, which focuses on the functional requirements of a system, usually
involves the objects of the system.
• From these objects, a UML class diagram can be created to illustrate the logical view.
• A class diagram establishes the vocabulary of the problem and resulting system.
• By defining all of the classes, their attributes, and their behaviours it becomes easy
to understand the key abstractions and terminology.
• Class diagrams are also useful for specifying database schemes.
• The class diagram makes it easier to see how classes interact and how data should
relate to each other in a database.
• Some of the most effective UML diagrams related to the logical view of a system are
the class diagram and the state diagram.
o Both the class diagram and the state diagram focus on the classes and objects of a system.

43
 9/25/2022

Kruchten’s 4+1 View Model

❑ Process View
• The process view focuses on achieving non-functional requirements.
▪ These are the requirements that specify the desired qualities for the system, which
include quality attributes such as performance and availability.
• The process view also presents processes that correspond to the objects in the
logical view.
• Some of the most effective UML diagrams related to the process view of a system
are the activity diagram and the sequence diagram.
• The activity diagram can illustrate the processes or activities for a system.
• The sequence diagram shows how objects interact with one another, which
involves how methods are executed and in what order.

Kruchten’s 4+1 View Model

❑ Development View
• The development view describes the hierarchical software structure.
• It also considers elements such as programming language, libraries, and toolsets.
• It is concerned with the details of software development and what is involved to
support that. This extends to management details such as scheduling, budgets, and
work assignments.
• Essentially, the development view covers the hierarchical software structure and
project management.
❑ Physical View
• The physical view handles how elements in the logical, process, and development
views must be mapped to different nodes or hardware for running the system.
• One of the most effective UML diagrams related to the physical view of a system is
the deployment diagram.
• It can express how the pieces of a system are deployed onto hardware or execution
environments.

44
 9/25/2022

Kruchten’s 4+1 View Model

❑ Scenarios
• Scenarios align with the use cases or user tasks of a system and show how the four
other views work together.
• For each scenario, there is a script that describes the sequence of interactions
between objects and processes.
• This involves the key objects defined in the logical view, the processes described in
the process view, the hierarchy identified in the development view, and the different
nodes specified in the physical view.
• Scenarios relate these elements to provide a complete picture.
• None of the views are fully independent of each other, with elements of some views
connected to others.
• The 4+1 view model can be molded to fit many situations to understand the
architecture of a software system.
• Being able to see a complex problem in many different perspectives helps make your
software more versatile.

Component Diagrams
• UML component diagrams are concerned with the components of a system.
• Components are the independent, encapsulated units within a system.
• Each component provides an interface for other components to interact with it.
• Component diagrams are used to visualize how a system’s pieces interact and what
relationships they have among them.
• Component diagrams are different from most other diagrams, as they show high-level
structure and not details like attributes and methods.
• They are purely focused on components and their interactions with each other.
• Component diagrams are a static view of the software system, and depict the
system design at a specific point in its development and evolution.
• Each component in a diagram has a very specific relationship to the other
components through the interface it provides.

45
 9/25/2022

Component Diagrams
• Component diagrams have ball connectors, which represent a provided interface.
• A provided interface shows that a component offers an interface for
others to interact with it.
• The provided interface means that client and consumer components
have a way of communicating with that component.

• Component diagrams also have socket connectors that display a required interface.
• The required interface is essential to the component diagram, to show
that a component expects a certain interface.
• This required interface is to be satisfied or provided by some other
component.

• Finally, component diagrams can illustrate an assembly relationship.

• An assembly relationship occurs when one component’s provided
interface matches another component’s required interface.
• The provided interface is depicted by a ball, and the required interface
is depicted by a socket.

Component Diagrams
❖To build a component diagram:
▪ First, you must identify the main objects used in the system.
▪ Next, the relevant libraries for the system need to be identified.
▪ Finally, the relationship between these components would need to be identified.
▪ When relevant libraries are identified, this extends to third-party implementation
dependencies, which should also be integrated into the diagram where relevant.

An example of a component diagram

for a video game system.

▪ Component diagrams are especially useful early in the design process, because of its high-
level emphasis.
▪ They can be drawn at different levels and allows you to focus not only on systems but on
subsystems as well.

46
 9/25/2022

Package Diagrams
• Sometimes, classes in object-oriented software are related in some way.
• A package groups together elements of software that are related.
• Elements can be related based on data, classes, or user tasks.
• A package can also define a “namespace” for elements it contains, that is, a package
is named and can organize the named elements of software into a separate scope.
• An element can be uniquely identified in the system by a fully “qualified name” that
is based on its own name and the name of the package that the element is in.
• Package diagrams show packages and the dependencies between them.
• These diagrams can organize a completed system into packages of related
packageable elements, which could include data, classes, or even other packages.
• Package diagrams help provide high-level groupings of a system so that it is easy to
see how a package contains related elements as well as how different packages
depend on each other.

Package Diagrams
• An example of a package diagram for a video game:
❖ Package diagrams can be
created at any stage of
development.
❖ They can also adapt and change
with the latest version of
software being worked on.
❖ Package diagrams are
particularly useful for technical
designers because they allow
them to see the dependencies
and relations between groups of
related elements.

47
 9/25/2022

▪ Packages are depicted by tabbed folders.

▪ If there are no elements to show in the package, then the package name goes into the
centre of the folder.
▪ If details are needed, there are two ways this can be expressed.

• The elements can be nested within the folder, as shown here:

• Alternately, this notation can be used:

• Here, a player package contains the movement interface, but it
is drawn below the folder in the diagram.
• This relationship is a composition, where the whole package
has an element as a part.
• Contained elements can also be listed in a package by their
names. These names can be partially qualified, but they should
be unique within the package.

• Notice in the above example that plus (+) and minus (-) signs
have been used to indicate if elements are public or private.
• Public elements can be accessed outside of the package by their
fully qualified names.
• Relationships are denoted through dotted-line arrows.
• A package can import an element from another package, as in the
example below where the Level package is importing Location from
the Player package.
• This brings the name Location into the Level namespace, particularly
for convenient use by elements in Level.
• As the import tag is public, the name is visible for further import
through the Level package.
• If a tag was private, the name would only be visible by elements within
the Level namespace and not further outside.

48
 9/25/2022

• A package can import the entire contents of other packages, as

in the example, where the User Interface package is doing a
public import of the Player package, as indicated by the import
tag, essentially doing public imports of the visible names of
elements in Player.
• The User Interface package is doing a private import of the
Buttons package, as indicated by the access tag, essentially
doing private imports of the visible names of elements in
Buttons. These names are not made further known outside the
User Interface namespace.

• Packages can also be merged, as in the diagram below.

• Merging typically occurs when two packages or concepts need to
come together into one.
• This is a use of generalization that allows different definitions to be
provided for the same concept.

Deployment Diagram
• UML deployment diagrams are used to visualize the deployment details of a
software system.
• The diagrams include more than just code, but also separate libraries, an installer,
configuration files, and many other pieces.
• In order for software to be ready to run, it is necessary to understand all the files
and executables involved and the environments where they reside.
• The deployment environment, or deployment target, can be very specific and
involve particular hardware devices.
• It can also be very general and involve supported operating systems.
• Details in a deployment diagram change accordingly.
• For example, software developed for Linux, MacOS or Windows may have differences
from one another.

49
 9/25/2022

Deployment Diagram
• Deployment diagrams deal with artifacts. Artifacts are a physical result of the
development process.
▪ Artifacts for a video game might include things like an executable to run the game, an
installer to install the game, audio libraries for sound, and multimedia assets.
▪ These are created as outcomes of producing the system and are the final pieces to be
put together.
❑There are two different types of deployment diagrams:
• specification-level diagrams
• instance level diagrams
• A specification-level diagram provides an overview of artifacts and deployment
targets, without referencing specific details like machine names.
• It focuses on a general overview of your deployment rather than the specifics.

Deployment Diagram
• An instance-level diagram is a more specific approach that maps specific artifacts to
specific deployment targets.
• They can identify specific machines and hardware devices.
• This approach is usually used to highlight the differences in deployments among
development, staging, and release builds.
• When creating deployment diagrams, it is important to use the correct notation for
the various elements.
• One of the most important aspects of the deployment diagram is the node.
• Nodes are deployment targets that contain artifacts available for execution.
• In a deployment diagram, they look like 3D boxes.
• Hardware devices are also displayed as 3D boxes, only they have a “device” tag on
them to differentiate them.
• A solid line between two nodes shows a relationship between deployment targets.
The line shows that the two nodes have a communication path between them.

50
 9/25/2022

Deployment Diagram

If an artifact is drawn inside a node box, this shows that an artifact is

deployed to a node. This also means that the artifact cannot function
without this deployment target.
Manifestation is a relationship where an artifact is a physical
realization of a software component. It can be represented with a
“manifests” indicator. , as below.

Here, the Player.class manifests the Player

component, which is the encapsulated unit
that contains all of the functionality of a
player.

Below is a specification-level deployment diagram for a simple video game.

This diagram provides a general and concise idea of how to deploy the application without providing
too much detail.

51
 9/25/2022

Deployment Diagram
• In a deployment diagram, there is a distinct hierarchy of deployment targets.
▪ You should start from the highest level of your deployment information, from
application name down to device and operating system.
▪ In this example, the application, the device, the operating system, and the execution
environment are all listed.
▪ When you look at each of these nodes, it is clear what environment is necessary to run
the application.
• Deployment diagrams help provide consistency and organization to deployments,
which helps avoid system failures.
• The diagrams also help keep track of the files and executables needed to deploy and
run the software.
• The diagram can be on an instance level specific to the deployment machines you
are using, or it can be general for a range of execution environments.

Activity Diagram
• A UML activity diagram allows the representation of the control flow from activity to
another in a software system.
• It captures the dynamic behaviour of the system and allows the mapping of
branching into alternative flows.
• Activities are actions that further the flow of execution in a system.
• They are actions that when completed cause another action to execute.
• For example, an action can alter or create new objects. These changes or actions can
drive your application forward.
To create an activity diagram, you must:
1. Identify the activities.
2. Identify the respective conditions of the system’s activities.
• Once activities and respective conditions have been determined, the activity
diagram can be created.

52
 9/25/2022

There are a few major parts to an activity diagram.

• There are start and end notes that look like labelled circles.
o These circles are where the diagram must begin.
o They show the starting activity that initializes the control flow of the application.
o The end node shows the final activity of the diagram.
o Intermediate activities are shaped like an oval, and they describe all of the activities that
change the game state before the game ends.

• Additionally, activity diagrams can include decision nodes.

• These are diamonds that have an activity leading into it,
• and there is the possibility of two alternative outcomes
as the next activity.
• The choice of outcome depends on how the condition
on the decision node evaluates.
All essential activities must be included in a diagram as well as the conditions.

An example of an activity diagram that illustrates a video game.

• In this example, the activity diagram begins by playing the game.
• The player then plays the level activity.
• When the level is complete, the player encounters the first
condition.
• If the score is high enough, then the player may move on to the
bonus level.
• If the player cannot play the bonus level, then the game is
ended, as denoted by a circle.
• Activity diagrams allow the mapping of concurrent activities that happen
in parallel.
• A fork in the flow moves into parallel flows, so activities can happen at
the same time. Parallel flows can join into a single flow.

• Activity diagrams allow you to see what activities and conditions should
be included in a system.
• As well, from the diagrams you see the order in which features are
encountered while also allowing for alternate flows to be taken into
account for the system.

53
 9/25/2022

Architecture Styles

54