Component Design and Modeling

1
Component Design and Modeling

• Chap 7

2
Contents

• Overview
• Component Viewpoint
• Component Interaction Viewpoint
• Component State Modeling
• Modeling highly configurable component
  architecture

3
Overview

• Component-based development
• Terminology
• Port and Interfaces

4
Component based Development

• A major trend in the construction of large scale
  software system.
• Facilitates reduced development times
• Increase system functionality
• Enable developers to utilize off-the-shelf
  software.
• Enables development teams to build and test parts
  of the system independently.
• Delivery of a software component to the
  integration and test team typically includes
  up-to-date documentation, test drivers, and
  communication specification for that component.

5
Component based Development

• Component implementation models
• COM, CORBA, and Java Beans all provide component
  implementation models.
• All these models vary in the details of required
  interfaces, allowed programming languages, and
  required environments.
• Component development often occurs in the context
  of distributed system development.

6
Terminology

• Definition of Component
• Component properties
• Origin of component
• Composite components
• Physical unit of replacement
• Preliminary component

7
Definition of Component

• UML definition of components
• Compile time object code libraries
• Link time executable files
• Run time in-memory instantiation of these build
  time constructs.
• Authors definition
• A physical set of object based or functional
  constructs that provides system functionality
  through well-defined communication mechanisms
  such as ports and interfaces.
• They are deployed as an executable, dynamic
  library, or via another runtime packaging
  technology.

8
Component Properties

• Always has the following properties
• Provides services through well-defined
  interfaces, ports, and interaction protocols.
• Encapsulates both state and behavior
• Depends only on a component framework or
  operating system to provide startup and
  communication to other components.

9
Component Properties

• Frequently has the following properties
• Obtained by purchasing rather than developing
• Operates in an independent process or thread of
  execution.
• Utilizes transparent distribution location via
  naming service or other location techniques.
• Has many configuration options, that may impact
  component behavior.
• Is developed, tested, and delivered independently
  of other components using object oriented
  concepts
• Is language independent, thus providing binary
  compatibility.

10
Origin of Component

• Subsystem
• The result of the build process for subsystem is
  one or more components.
• The component built by a particular subsystem may
  also include entities from other subsystems.
• These other subsystems merely provide the build
  time entities so that the component can be built.
  They are not the origin subsystem.

11
Composite components

• Group a set of components together into a single
  logical component.
• A form of abstraction that allows modeling of
  large sets of components at a higher level of
  abstraction.
• Represents the union of all the functions and
  interfaces of the grouped components.

12
Physical unit of replacement

• Is important for system evolution.
• If a component supports replacement, it limits
  the impact for software upgrades to only the
  modified components.
• Is possible because of well-defined
  configurations and communication mechanisms.

13
Preliminary component

• During initial system design, some components may
  be nothing more than a list of functions and a
  rough set of interfaces.
• As the design progresses, the component
  definitions are expected to change.
• Sometimes, it is called conceptual component.
• Eventually, it should be evolved into the actual
  components to be delivered.

14
Port and Interfaces

• Interface
• A class that provides the means by which external
  components communicate with the component that
  provides the interface.
• Focuses on defining a set of methods to be
  invoked by a client (synchronous)
• Generally implemented as methods on a class or
  using mechanisms such as CORBA, COM/DCOM, Java
  RMI, as well as a native language function.
• Port
• A class that is used to denote communication of a
  particular category of messages.
• Messaging specifies a data schema and a protocol
  (asynchronous, support broadcast)

15
Component Viewpoint

• Component communication
• Component interfaces
• Message based component modeling
• Combining interfaces and messaging
• Comparison of interfaces and messaging
• Mechanism and performance annotation

16
Component communication

• Interface
• Data pull
• Synchronous
• Query information
• Point to point
• Messaging
• Data push
• Asynchronous
• For smaller amount of data
• Publication/subscription approach
• P2p and broadcasting

17
Component Interfaces

• Fig 7.1 component view with interfaces
• Provides an overview of the major runtime
  components that make up the system.
• It highlights the interfaces utilized for
  communication among the components.
• The information for this system view is likely
  available well before system construction begins.
• Multi-instance components
• This view does not constrain the process and
  thread structure of the solution.
• The external type on the web browser component
  indicates that this component is not a part of
  the system under design.
• Table 7.2, 7.3
• Fig 7.2 composite component example

18
Message based component modeling

• Messages between components are typically
  asynchronous and may have highly variable
  transmission rates over time.
• Key questions concerning message-oriented
  component interactions
• What are the protocols in which a component
  participates?
• Is the component a sender or receiver for these
  protocols?
• What processing functionality does a component
  provide as a result of sending or receiving these
  messages?
• Is the information in the message sufficient for
  the component to act accordingly?
• What are the peak messaging rates?

19
Message based component modeling

• Fig 7.3
• Table 7.4 component description Table 7.5
• Combining interfaces and messaging
• Fig 7.4, Table 7.6
• Relationship components and messaging Fig 7.5
  (build time component dependency concept-message
  oriented)
• Relationship components and interface Fig 7.6
  (build time component dependency
  concept-interface oriented)
• Mechanism and performance annotations (fig 7.7)

20
Component Interaction Viewpoint

• Dynamic aspect of components are modeled in two
  ways.
• Component interaction
• Component state viewpoint.
• Component interaction
• Utilizes component level sequence or
  collaboration diagrams to show how specific
  components will interact. (T 7.8)
• Fig 7.8 scale better than object interaction
  diagrams since the details of the individual
  object instances are not shown.
• Fig 7.9 collaboration diagram when the
  communicating entities fit easily on one page,
  and the number of interactions is not too large,
  usually less than 10.

21
Component State Modeling

• Provides a means to communicate the internal
  states and activities for one or more components.
• Provides visibility into the overall behavior of
  the component(s)
• By illustrating the potential states of a
  component along with the transitions among the
  states, or
• By illustrating the flow of control from one
  activity to another
• Table 7.9 component state viewpoint
• Fig 7.10 state view 7.11 activity view
  represent activity relationship such as join,
  fork, branches.

22
Modeling Highly Configurable Component
Architecture

• Standard UML modeling techniques model static
  architecture well, but are not as good at
  representing dynamic component architectures
• Components that are made available dynamically as
  requests are made.
• Can be shown by using the creation and
  destruction semantics in component interaction
  views.
• How to represent components that have many
  different configuration options.
• Use annotations to indicate interfaces emphasized
  or de-emphasized.