Component Basics

CS6961 – Lecture 6

Nathan Dykman

University of Utah SoC CS6961 - Lecture 6 2

What We Covered

• We have introduced the concepts of class modeling, sequence modeling and use cases– Often, this is the core “triad” of UML models

• In the next section, we will be introducing component modeling in UML– As well as basic component concepts in

software systems.

University of Utah SoC CS6961 - Lecture 6 3

Administration

• Due date extension:– Project is now due by Friday, 05:14:59PM

• You can hand it in now, if you just want to get it over with

• Or you can resubmit if you already handed it in.

• Any questions?– Okay, moving bravely on.

University of Utah SoC CS6961 - Lecture 6 4

Components

• Let’s spent a little time and brainstorm about what components are (or could be)– For those of you that haven’t heard the term

before, think about it in more general terms.

University of Utah SoC CS6961 - Lecture 6 5

Components

• Components– Are a set of consistent software functionality

that can be deployed independently• Or as an interdependent part of a system

– Provide a consistent interface for accessing functionality

• Allowing the implementation of that functionality to vary independently of that interface.

University of Utah SoC CS6961 - Lecture 6 6

Components and Classes

• Could classes be considered components?– Independent unit of deployment?

• Sort of. (.class files, .netmodule, .lib)

– Consistent Interface• Sure. We have public methods, etc.

– Implementation/Interface independence?• Depends on how the class coded, it seems.

University of Utah SoC CS6961 - Lecture 6 7

Components and Classes

• Okay, what if we add in interfaces– Java, C# interfaces (C++: Pure Virtual

Classes)– Helps with implementation/interface

independence.

• So, what makes components different from classes?

University of Utah SoC CS6961 - Lecture 6 8

Component Key Ideas

• Key idea: Components can be (ideally) deployed independently in a system– So, you should be able to add a new version

of a component to a system without having to rebuild (or link) the whole system

• Why is this important?

– What do you need to have to make this work?• Hint, think runtime and design time.

University of Utah SoC CS6961 - Lecture 6 9

Components

• Key Idea: Components are a reification of the concept of a class applied to a set of classes.– In lay terms, classes map to components like

so• Public Methods Public Interfaces• Private Methods Private Classes

– In a sense, we can treat a whole set of classes in a “class-like manner”

University of Utah SoC CS6961 - Lecture 6 10

APIs to Frameworks

• For a long time, we had libraries that provide a set of calls to other programs– Standard C library, Base Win32 Library,

POSIX/Unix libs, etc.• Still a very useful programming model

• In modern programming languages, we want OO-based APIs– We call these frameworks

University of Utah SoC CS6961 - Lecture 6 11

Frameworks in C++

• C++ provides a set of OO libraries, of course– IOStreams, STL, Boost.

• However, reuse at the binary level is very tricky.– In fact, in the worse case, you have to

recompile a program to a new version of a library

• In the best case, you can relink, but…

University of Utah SoC CS6961 - Lecture 6 12

C++ and Headers

• Just like C, you need header files to be able to use a library.– All those #include statements are important.

• Also, there is no standard binary linkage for C++ classes– Since C++ was first built on top of the C linker,

OO information was stripped out of the binaries

• Templates make this even more complicated.

University of Utah SoC CS6961 - Lecture 6 13

COM and CORBA

• While we don’t cover either of these in much detail, both of these technologies try to address this problem of reusing objects in C++– COM is a MS technology, still widely used– CORBA is used more often in distributed

object worlds, being replaced by Java, .Net and Web Service technologies.

University of Utah SoC CS6961 - Lecture 6 14

Components in Modern Languages

• Newer languages solve the header problem by compiling the OO information alongside the bytecode for the class– This means that in the best case, we don’t

need to even relink a program to use a newer library of classes

• The class loader takes care of all the binding we need at runtime.

University of Utah SoC CS6961 - Lecture 6 15

Components in Modern Languages

• This information allows us advanced capabilities like reflection– Without having this information, reflection at

runtime can’t work.

• In some cases, reflection can be very powerful– JUnit requires it, as do many other

frameworks in Java, .Net, etc.

University of Utah SoC CS6961 - Lecture 6 16

Components in UML

• Components in UML provide an design abstraction that matches the basic ideas of components. – A component in UML can provide a set of

classes, interfaces to other components, etc.• This set of element is called the component

interface.

– A component in UML can realize a set of classes, etc. that implements the component interface

University of Utah SoC CS6961 - Lecture 6 17

Components in UML

• Additionally, UML supported the concept of a required interface– This shows that a component requires

another component to provide an compatible interface to use its functionality

– This is not directly supported in any standard programming framework yet

– But it is a useful and common concept• Work in contract languages reflects this.

University of Utah SoC CS6961 - Lecture 6 18

Components In UML

• There are a number of notational variations in UML to show component models– Each shows a level of detail. – There are also some tool variations in the

notational variations supported• This is annoying at best• For example, the compartment view isn’t very

commonly supported

University of Utah SoC CS6961 - Lecture 6 19

Component Model: Lollipop View

id Component Model

Application ServerDatabase Serv er

ILoadPageIRequestPage

University of Utah SoC CS6961 - Lecture 6 20

Lollipop View

• In this case, the provided interfaces are shown as circles, and there is an association between component to interface (this is the lollipop)– These are classes/interfaces, but with no details

shown (only name)

• The solid line from a component to a class shows that the component provides the interface

• A dashed arrow line from component to interface shows that the component requires the interface.

University of Utah SoC CS6961 - Lecture 6 21

Component Model: Expanded Viewid Component Model

Application Server

Database Serv er

«interface»

ILoadPage

+ LoadPageByKey() : Page

«interface»

IRequestPage

University of Utah SoC CS6961 - Lecture 6 22

Expanded View

• This is the same as the previous example, but the interfaces are now expanded to show detail– I don’t prefer this view, as it is often more

cluttered that is required.

• Also, some tools show provided interfaces with an implements relationship– Shown as a dashed line with a open triangle

from component to interface

University of Utah SoC CS6961 - Lecture 6 23

Compartment View (RSA)

University of Utah SoC CS6961 - Lecture 6 24

Compartment View

• Rational Software Architect supports a compartment view of components– The second compartment is the required

interfaces– The third compartment is the provided

interfaces– Components are then associated with each

other. (plain line, no arrows).

University of Utah SoC CS6961 - Lecture 6 25

Warning: UML Distilled

• In chapter 5, there is talk about “Ball and Socket Notation”– This allows a component to show a required

interface as a socket. This is still allowed.– But the notation showing an assembly as a

connected ball and socket is no longer supported.

• However, some tools still use it. This is bad.

University of Utah SoC CS6961 - Lecture 6 26

Bad Example

id Component Model

ComponentA ComponentB

University of Utah SoC CS6961 - Lecture 6 27

Advanced Concepts

• UML also supports the concept of a port for components– A port is a specific connection point for

interfaces (both provided and required). • It can serve as a “gate for messages” as well.

– Useful in modeling SOA-based or event-based software systems.

– We will discuss this more later when we cover structured classes and composite structures.

University of Utah SoC CS6961 - Lecture 6 28

Component Structure

• Components can have artifacts– These represent the physical files, resources,

etc. of a component

• Components can nest– Components can contain other components

• There is a practical limit to how this nesting works.

University of Utah SoC CS6961 - Lecture 6 29

Components and Subsystems

• For large scale projects, it makes sense to split the system into subsystems– Subsystems provide a set of components to

other subsystems and systems– Subsystems have a set of components that

implement/support those provided components.

University of Utah SoC CS6961 - Lecture 6 30

Subsystem Examplesid Subsystems

Application Layer

Data Layer

University of Utah SoC CS6961 - Lecture 6 31

Model Management

• If you remember, UML has packages– Packages can contain any elements– This allows us to organize UML models into a

hierarchy (much like a file system)

• Subsystems are modeled in UML as a special kind of package– Technically, a stereotype of package.

University of Utah SoC CS6961 - Lecture 6 32

Next Time:

• We discuss the reason behind the use of components, and the relationship of components to architecture– Later on, we will discuss more concepts in

software architecture

• Reading: I recommend you check out Chap. 4,5 and 14 in UML Distilled– I may have a paper for reading as well.