1 of 37

Component-Level Design (CLD)

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

Creating reusable components in high quality.

2 of 37

Who am I?

Thank you for stopping by.

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

You can view the Introducing Myself, if you want to know a little more about who I am.

All my presentations and materials are free and available at my blog post: Software Engineering.

Don’t let me uphold you,

continue your journey, go to next slide.

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

3 of 37

Agenda

Intro
Quick Look
What Is A Component?

An Object-Oriented View
The Traditional View
A Process-Related View

Component-Based Development
Threat Modeling, Prioritization, And Mitigation

4 of 37

Intro

CLD - Component-Level Development occurs after the first iteration of architectural design has been completed.

Overall data and program structure of the software has been established
Translate the design model into operational software

The translation can be challenging

Follow a set of design principles that not only perform the translation but also do not "introduce bugs to start with."

5 of 37

Quick Look

What is it?

Defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component

Who does it?

Software engineers

Why is it important?

To determine whether the software will work before you build it
To review the details of the design for correctness and consistency with other design representations
Assessing whether data structures, interfaces and algorithms will work

6 of 37

Quick Look

What are the steps?

Design representations of data, architecture and interfaces form the foundation
Design notation encompasses UML diagrams and supplementary forms
Procedural design is specified using a set of structured programming constructs

What is the work product?

Each component, represented in graphical, tabular, or text-based notation, is the primary work product

How do I ensure that I've done it right?

A design review is conducted

7 of 37

What’s a Component?

A modular building block for computer software.

Defined by OMG Unified Modeling Language Specification

"a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces."

The true meaning of the term component will differ depending on the point of view of the software engineer who uses it

Lets examine 3 important views, Object-Oriented, Traditional and Process-related.

8 of 37

The Object-Oriented View

A component(also called a class ) is an entity with functional- and data elements in program, which encapsulates an abstraction of a real-world object, with data and its needed processing logic.

9 of 37

An Object-Oriented View

Analysis Class

Design�Component

Elaborated design class

10 of 37

An Object-Oriented View

During requirements engineering, an analysis class called PrintJob was derived.

The attributes and operations defined during analysis

During architectural design, PrintJob is defined as a component within the software architecture

Represented using the short hand UML notation

PrintJob has 2 interfaces:

computeJob, which provides job costing capability
initiateJob, which passes the job along to the production facility

Represented using the "lollipop" symbols of the component box.

11 of 37

An Object-Oriented View

The elaborated design class PrintJob contains more detailed attribute information as well as an expanded description of operations required to implement - Figure 11.1

computeJob and initiateJob imply communication and collaboration with other components (not shown)

Example

computePageCost() (part of the computeJob interface) might collaborate with a PricingTable component that contains job pricing information
checkPriority() operation (part of the initiateJob interface) might collaborate with a JobQueue component to determine the types and priorities of jobs currently awaiting production

12 of 37

The Traditional View

A component(also called a module ) is a functional element of a program that incorporates processing logic.

13 of 37

The Traditional View

Serves 1 of 3 important roles:

Control component that coordinates the invocation of all other problem domain components
Problem domain component that implements a complete or partial function that is required by the customer
Infrastructure component that is responsible for functions that support the processing required in the problem domain

14 of 37

The Traditional View

Control components (modules) reside near the top of the hierarchy (program architecture)

Problem domain components tend to reside toward the bottom

15 of 37

The Traditional View

Note…

The shaded boxes are equivalent in function to the operations defined for the PrintJob class discussed earlier.
In this case, however, each operation is represented as a separate module that is invoked
Other modules are used to control processing and are therefore control components

The behavior of the module is sometimes represented using a state diagram.

16 of 37

The Traditional View

Consider the module ComputePageCost.

The intent of this module is to compute the printing cost per page based on specifications provided by the customer.

Data required to perform this function are:

number of pages in the document
total number of documents to be produced
one- or two-side printing
color requirements
size requirements

ComputePageCost uses these data to determine a page cost that is based on the size and complexity of the job.

17 of 37

The Traditional View

18 of 37

The Traditional View

ComputePageCost module accesses data by…

invoking the module getJobData
…which allows all relevant data to be passed to the component and a database interface, accessCostsDB
…which enables the module to access a database that contains all printing costs

Algorithm detail can be represented using the pseudocode text shown in the figure or with a UML activity diagram.

19 of 37

The Process-Related View

A process that emphasizes the design and construction of reusable software component.

20 of 37

A Process-Related View

Assumes the component is being designed from scratch.

These components have been created with:

Reusability in mind.
Complete description of their interface, the function(s) they perform, and the communication and collaboration they require.

Middleware is a collection of infrastructure components that enable problem domain components to communicate with one another across a network or within a complex system.

21 of 37

Component-Based Development

CBSE – Component-based software engineering

A process that emphasizes the design and construction of computer-based systems using reusable software component

22 of 37

Designing Components�Step by step

A 7 steps guide to design quality software components.

23 of 37

The 7 Steps

Note: The term diagrams, in these steps refers to well-known UML diagrams.

1. Identify design classes that correspond to the problem domain.�

2. Identify design classes that correspond to the infrastructure domain.

3. Elaborate the design classes not acquired as reusable components.

Specify message details when classes and components collaborate, via collaboration diagrams.
Identify appropriate interfaces for each components.
Describe processing flow within each operation in detail, via activity diagrams.

4. Describe persistent data sources (databases and files) and identify the classes required to manage them.

24 of 37

The 7 Steps (continued)

5. Develop and elaborate behavioral representation for a class/component.

Go through all relevant use-cases, relevant for a design class.
Get insights into the states the design class goes through, via state diagrams.

6. Elaborate deployment diagrams to provide additional implementation detail.

7. Refactor, every component-level design representation and always consider alternatives.

25 of 37

Component-Based Development (CBD)

Used to reduce lead time, generate greater return on investment (ROI), leverage costs of developing components, enhance quality and ease maintenance of component-based applications.

26 of 37

Why Component-Based Development (CBD)?

Is it possible to construct complex systems by assembling them from a catalog of reusable software components?
Can this be accomplished in a cost- and time-effective manner?
Can appropriate incentives be established to encourage software engineers to reuse rather than reinvent?
Is management willing to incur the added expense associated with creating reusable software components?
Can a library of components necessary to accomplish reuse be created in a way that makes it accessible to those who need it?
Can existing components be found by those who need them?�

“The answer to each of these questions is yes”.

27 of 37

CBD - Process

Start with the system requirements
Search the repository to see if any already exists
Check if Precondition & Postcondition are satisfied

If no satisfied component can be found…decide to:

Modify the requirements, or
Modify an already existing component that most closely matches

28 of 37

CBD - Advantages

Reduced lead time

It is faster to build complete applications from a pool of existing components.

Greater return on investment (ROI)

Sometimes savings can be realized by purchasing components rather than redeveloping the same functionality in-house

Leveraged costs of developing components

Reusing components in multiple apps spread the costs over multiple projects.

Enhanced quality

Components are reused and tested in many different applications.

Maintenance of component-based applications

With careful engineering, it’s relatively easy to replace components with new or enhanced components.

29 of 37

CBD - Risks

Component selection risks

It is difficult to predict component behavior for black-box components, or there may be poor mapping of user requirements to the component architectural design.

Component integration risks

There is a lack of interoperability standards between components; this often requires the creation of "wrapper code" to interface components.

Quality risks

Unknown design assumptions made for the components makes testing more difficult, and this can affect system safety, performance, and reliability.

Security risks

A system can be used in unintended ways, and system vulnerabilities can be caused by integrating components in untested combinations.

System evolution risks

Updated components may be incompatible with user requirements or contain additional undocumented features.

30 of 37

Threat Modeling, Prioritization & Mitigation

An approach for creating an abstraction of a software system, aimed at identifying attackers’ abilities and goals.

31 of 37

Threat Modeling, Prioritization & Mitigation

TMM – Threat Modeling Method

An approach for creating an abstraction of a software system, aimed at identifying attackers’ abilities and goals, and using that abstraction to generate and catalog possible threats that the system must mitigate.

STRIDE - The most well-established TMM

Modeling a system with data flow diagram and mapping the DFD’s - (Data Flow Diagrams) elements to the 6 threats categories
Determining threats, documenting the threats and steps for their prevention

32 of 37

Threat Modeling, Prioritization & Mitigation

Threat categories and security properties.
Also called, STRIDE, from first letter from every threat.

Threat	Security Property
Spoofing	Authentication
Tampering	Integrity
Repudiation	Nonrepudiation
Information	Confidentiality
Denial of service	Availability
Elevation of privilege	Authorization

33 of 37

Threat Modeling, Prioritization & Mitigation

Threat categories of DFD - Data Flow Diagrams.

Element	Spoofing	Tampering	Repudiation	Information Disclosure	Denial of Service	Elevation of Prililege
Data flows		X		X	X
Data stores		X		X	X
Processes	X	X	X	X	X	X
External entity	X		X

34 of 37

Threat Modeling, Prioritization & Mitigation

Once the threats have been identified, mitigation strategies can be developed and prioritized. Typically, based on cost and value considerations.�
Considering the cost of implementing the mitigation strategy is important, but it’s equally important to also consider cost of not implementing it, which is reflected in value.�
Remember that risks that are realized result in cost that not only expressed in terms of dollars, but could also reflect loss of reputation, loss of trust and even loss of life.

1 of 37

2 of 37

3 of 37

4 of 37

5 of 37

6 of 37

7 of 37

8 of 37

9 of 37

10 of 37

11 of 37

12 of 37

13 of 37

14 of 37

15 of 37

16 of 37

17 of 37

18 of 37

19 of 37

20 of 37

21 of 37

22 of 37

23 of 37

24 of 37

25 of 37

26 of 37

27 of 37

28 of 37

29 of 37

30 of 37

31 of 37

32 of 37

33 of 37

34 of 37

35 of 37

36 of 37

37 of 37