CBD process definition

spinabundantInternet and Web Development

Jul 30, 2012 (5 years and 22 days ago)

387 views




Page
1

-

39




























Component Based Development




























Page
2

-

39


Table of Contents


1

INTRODUCTION

................................
................................
................................
.............................

3

2

COMPONENT BASED DEVE
LOPMENT

................................
................................
.......................

4

3

COMPONENT BASED DEVE
LOPMENT PROCESS

................................
................................
.....

5

3.1

I
NTRODUCTION
................................
................................
................................
............................

5

3.2

O
VERVIEW OF PHASES

................................
................................
................................
................

6

4

DESCRIPTION OF THE P
HASES

................................
................................
................................
..

8

4.1

S
OLUTION
A
RCHITECTURE

................................
................................
................................
...........

8

4.2

G
LOBAL
A
NALYSIS

................................
................................
................................
....................

10

4.3

P
LAN
L
OGICAL
I
NCREMENTS

................................
................................
................................
......

12

4.4

D
ELIVERABLES
A
SSESSMENT

................................
................................
................................
.....

13

4.5

D
ETAILED
A
NALYSIS

................................
................................
................................
..................

13

4.6

P
LAN
T
ECHNICAL
I
NCREMENTS

................................
................................
................................
..

15

4.7

D
ESIGN
&

B
UILD

................................
................................
................................
.......................

15

4.8

C
OMPONENT
T
EST

................................
................................
................................
....................

18

4.9

C
OMPONENT
I
NTEGRATION
T
EST

................................
................................
...............................

19

4.10

C
OMPONENT
A
CCEPTANCE

................................
................................
................................
.......

19

4.11

A
SSEMBLY

................................
................................
................................
................................

19

5

APPENDICES

................................
................................
................................
................................

21

5.1

A
PPENDIX
A:

P
LANNING
L
OGICAL AND
T
ECHNICAL
I
NCREMENTS


E
XAMPLE

................................

21

5.2

A
PPENDIX
B:

C
HECKLISTS

................................
................................
................................
.........

22

5.3

A
PPENDIX
C:

L
OGICAL
I
NCREMENT
P
LAN
T
EMPLATE

................................
................................
...

29

5.4

A
PPENDIX
D:

T
ECHNICAL
I
NCREMENT
P
LAN
T
EMPLATE

................................
...............................

30

5.5

A
PPENDIX
E:

M
APPING TO
T
ECHNICAL
A
RCHITECTURE
E
XAMPLE

................................
................

31

5.6

A
PPENDIX
F:

U
SING
S
ELECT
E
NTERPRI
SE

................................
................................
..................

32

5.7

A
PPENDIX
G:

T
ERMINOLOGY
................................
................................
................................
......

33

5.8

A
PPENDIX
H:

R
EFERENCES

................................
................................
................................
.......

39





Page
3

-

39


1

Introduction

This document describes the Component Based Devel
opment (CBD) process. The document focuses on the
primary CBD process, consisting of a number of phases with their description, inputs to each phase, tasks and
deliverables.




Page
4

-

39


2

Component Based Development

Although object
-
oriented development has been a boon
to software engineering, it has fallen short of its goal of
speeding application development in corporate environments. Component
-
based development represents the
next stage in the evolution of software development, promising to shorten development life cy
cles, reduce skill
requirements, and cut costs associated with custom development. Component
-
based development solves many
of the shortcomings of object
-
oriented programming and focuses on capturing business logic. Its premise is the
creation of reusable a
nd adaptable component assemblies.

In a sense, component
-
based development represents the industrialisation of the software development
engineering process based on the assembly of common, tested elements. Component
-
based development
assumes that there are

enough common elements in large software systems to justify developing reusable
components that can be easily implemented in many applications.

The easiest way to think of component
-
based development is to look at the more
-
established engineering
discipli
nes such as mechanical engineering. It would be ludicrous to design and build every bolt, cable and
girder of a suspension bridge from scratch. Such a project would be far too expensive and time
-
consuming to be
economically viable.

Borrowing from computer
hardware design, component
-
based development is often described as the software
equivalent of integrated circuits that are plugged together to form systems


much as modern PCs assembled
with off
-
the
-
shelf motherboards and hard drives. The idea of componen
t
-
based development is that application
development becomes an assembly process, built on substantial reuse of standard components. In theory, a large
portion of an application can be based on reused software.

Unlike PC hardware components, software has th
e added dimension of abstraction. A software component can
represent a person as an employee, a customer, or vendor and its not limited by the physical characteristics of
the person. A software component can also be assembled and reassembled in different a
pplications to change its
characteristics.

As shown in figure 1, the requirement specifications obtained from the customer along with the Quick Scan are
used to produce the Solution Architecture and then the Project Work Plan (PWP). These act as input for
performing the Global Analysis. Subsequently, Detailed Analysis and Design & Build phases are executed to
develop components. These components are then assembled together to form the application during the
Assembly phase.




Page
5

-

39


3

Component Based Development Pro
cess

3.1

Introduction

The diagram below provides an overview of the primary CBD process. Activities that deal with non
-
primary
process issues, such as project management, test management, quality management and component
management, are not within the scope of

this document. Different phases of the process can be executed at
different geographical/physical locations. For details of the various applicable CBD process scenarios, please
refer to Multi
-
site Development Model [8].

Design & Build and Component Test
Acceptance & Assembly
Analysis
Solution Definition
Java Development
Non-Java Development
Solution
architecture
Analysis
Plan logical
increments
Design &
build
Component
test
Design &
build
Assembly
Component
acceptance
Plan technical
increments
Component
test
Test & Roll-out
ST
FAT
Deliverables
assessment

Component
integration test
Component
acceptance
Component
integration test
PWP
Business
Requirements
Deliverables
assessment

Figure
1
: Primary CBD Process




Page
6

-

39


3.2

Overview of phases

3.2.1

Business Requirements

This phase provides Business view of the system to be developed. When agreed by both parties, the document
produced during this phase, serves as a contract between the

Business and the Developers.

3.2.2

Solution Architecture

Solution Architecture phase is executed by Solution Architects based on the template [7]. This phase requires
business and technical knowledge and hence requires business and development team involvement.

Solution
Architecture deliverables serve as the starting point for the Analysis phase of the CBD Process.

3.2.3

Project Work Plan

The Project Work Plan (PWP) provides the comprehensive planning for executing the project. The sections of
Project Work Plan that c
an serve as an input to the Analysis phase are objective and scope of the project, design
considerations, decision points, secondary requirements and risk measures. These can be found in the first four
chapters of Project Work Plan document template [6].

3.2.4

Plan Logical Increments

In this activity, logical increments are identified. The identification of these increments should be influenced by
external factors, e.g. customer, dependencies. This work should be in consultation with the customer. For
instance,
if the Business wants the functionality to be delivered in different increments. This can be achieved by
planning the required versions as logical increments. One possible realisation could be by aggregating a number
of use cases for each increment. Increm
ents may be developed in parallel, i.e. an increment is in progress while
part of another increment is also being worked on. The planning aspect is a typical project management activity.
Refer to Appendix C for a template of a Logical Increment Plan.

3.2.5

Analy
sis

The purpose of the Analysis phase is to clearly and unambiguously detail the business requirements in terms of
a set of models comprising business, user and data components. Subsequently, its deliverables can be shipped to
another organisational unit f
or design and build. For further details as how to execute the Analysis Phase, refer
to the Guidelines to Execute CBD Process document [9].

3.2.6

Plan Technical Increments

This activity focuses on partitioning of system and ordering the partitions in which the a
ctual design and build
will take place. The partitions may be interdependent. For each application, there can be zero or more logical
increments, and for each logical increment there can be one or more technical increments. Refer to Appendix D
for a templa
te of a Technical Increment Plan.

3.2.7

Deliverables Assessment

The deliverables from the Analysis phase are assessed. If required, feedback is provided to the team that
performed the Analysis. The phase ends with a formal assessment of the deliverables.

3.2.8

Design
& Build

The Design & Build phase concerns the elaboration of the analysis results (i.e. use case diagrams, sequence
diagrams, class models and component model) and the actual realisation into code. As a starting point, every
logical component will have a t
echnical equivalent, but for realisation additional classes may be added. For
further details as how to execute the Design & Build phase, refer to the Guidelines to Execute CBD Process
document [9].




Page
7

-

39


3.2.9

Component Test

Component

testing verifies whether the com
ponent fulfils the requirements set in the Component Specification.
This specification contains information on all component aspects, including performance, reliability, downward
compatibility, concurrent use and exception handling.
The development team ty
pically executes this phase. For
further details as how to execute this test, refer to the Process and Procedures for CBD Testing at AAGITS [10].

3.2.10

Component Integration Test

The Component Integration Test is aimed at testing a
subsystem
, consisting of the range of components (i.e. user
services, control, business and I/O components) that implement one specific use case.
The development team
typically executes this phase. For further details as how to execute this test, refer to the Proce
ss and Procedures
for CBD Testing at AAGITS [10].

3.2.11

Component Acceptance

The Component Acceptance phase formally tests the components received from Design & Build. The
Component Test phase should deliver the necessary drivers and stubs. The test basis comes
directly from the
Analysis phase. For further details as how to execute this test, refer to the Process and Procedures for CBD
Testing at AAGITS [10].

3.2.12

Assembly

In the assembly phase the components associated with an application (release) are assembled. Thi
s application
will be offered to the System Test. For further details as how to execute this test, refer to the Process and
Procedures for CBD Testing at AAGITS [10].

3.2.13

System Test

System Testing is typically
black box testing

of integrated hardware and soft
ware to verify that it meets
specified
requirements
. System testing takes place after all software modules in the system have successfully
completed the Unit & Component Integration test levels.

The objective of system testing is to validate the integrat
ion of individual software units into a working system,
and to test the
interfaces

among software modules both upstream and downstream.
For further details as how to
execute this test, refer to the Process and Procedures for CBD Testing at AAGITS [10].

3.2.14

Fun
ctional Acceptance Test

Functional Acceptance Testing involves the Business in validating the operation of the system according to the
overall project requirements, with the emphasis on the business requirements.
For further details as how to
execute this
test, refer to the Process and Procedures for CBD Testing at AAGITS [10].




Page
8

-

39


4

Description of the phases

4.1

Solution Architecture

4.1.1

Objective

The Solution Architecture phase is executed in co
-
operation with the Business, based on the Solution
Architecture Template [7]. The purpose of Solution Architecture is to define a firm basis for the project by
focussing on architectural requirements. Its d
eliverables help in preparing Project Work Plan and serve as the
starting point for the Analysis phase of the CBD Process.

4.1.2

Input



Business Requirements / Quick Scan

4.1.3

Tasks

Following are the tasks to be carried in Solution Architecture phase with their brief

description. For further
details as how to execute each task refer to the Solution Architecture Template [7].


1.

D
EFINE OBJECTIVE OF T
HE PROPOSED SOLUTION

Clearly define the objective of the proposed solution and provide a summary of the requirements to
und
erstand the scope of the project. A list of concurrent CBD projects that are involved in similar kind of
areas (i.e. business, methodology, technology … etc) should be identified to achieve reuse at different
levels.

2.

A
NALYSE
&

D
ETAIL REQUIREMENTS

The requi
rements that are given as an input to Solution Architecture are analysed in terms of completeness,
consistency and clarity. The requirements are then further detailed, with the help of the Business, into such
a level that they can be considered complete, c
onsistent and unambiguous for executing subsequent phases.

3.

D
EFINE HIGH
-
LEVEL ARCHITECTURES

Based on the requirements, define following high level architectures and a list of concurrent projects for
each of these architectures that have a cross
-
impact.



Bus
iness Process Architecture

The flow of actions in a particular sequence that completes a particular business task/process are
modelled to understand the working of actual business and consequently the layout of the proposed
solution. Workflow diagrams are
a good means to develop and understand business process
architecture. If the workflow of business processes is not provided as an input to Solution Architecture
then this task is completed here with the help of Business.




Logical Component Architecture

Ba
sed on requirements, define initial logical components diagram to provide a component view of the
application. At this stage only high level description of a component is required to understand its
functionality and usage. This logical component architectu
re will outline a solution to achieve reuse of
already built components. Additionally a survey on concurrent CBD projects is important to avoid
multiple projects creating similar components.




Logical Application Architecture

The position of the new
application among the other applications of the ISAP has to be determined.
The dependencies and the changes required in other applications (if any), for the new application to
work properly should also be identified at this stage.





Page
9

-

39








Technical Architecture

The framework of application in terms of Layers, Environment, Technology, Operating System, Database,
Communication, Security, Performance and other Enterprise constraints is known as Techni
cal
Architecture. At this stage these things need to be defined at a high level and if the project is following any
already available architecture then references to that architecture should be provided.

4.1.4

Deliverables



Objective of the proposed solution



List

of concurrent CBD projects



List of complete, consistent and unambiguous business requirements



High
-
Level Architectures:



Business Process Architecture



Logical Component Architecture



Logical Application Architecture



Technical Architecture


Business Processes that need to be supported by the
application
Layers,
Environment, Technology, Operating System,
Database, Communication, Security, Performance &
Enterprise Constraints
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Application
Application
Application
Business Process
Architecture
Logical Application
Architecture
+
Logical Component
Architecture
Technical Architecture



Page
10

-

39


4.2

Global Analysis

4.2.1

Objective

The Analysis phase can be split into Global Analysis and Detailed Analysis. The purpose of the Global Analysis
phase is to clearly and unambiguously detail the business requirements in terms of a set of models.
Subsequently, its deliverables can
be shipped to another organisational unit for detailed analysis, design and
build.

4.2.2

Input



Business Requirement



Solution Architecture Deliverables



Project Work Plan

4.2.3

Tasks

Following are the tasks to be carried in Global Analysis phase with their brief descrip
tion. For further details as
how to execute each task refer to the Guidelines to Execute CBD Process document [9].


0.

C
OMPLETE BUSINESS PRO
CESS MODEL

The business process model may not have been completed during the Solution Architecture. In that case, it
sh
ould be completed at the start of the Global Analysis.

1.

D
EFINE
/
CONFIRM THE INITIAL
LOGICAL COMPONENT AR
CHITECTURE

The initial logical component architecture contains all relevant logical components, based on the business
requirements from the Solution Archi
tecture phase. Initial Logical Component Architecture if not described
in the Solution Architecture is described and then confirmed during the Global Analysis phase. Should the
architecture not yet be elaborated to a sufficient level of detail, this elabor
ation is also considered a
deliverable of the Global Analysis.

2.

I
DENTIFY THE ACTORS A
ND DEVELOP THE USE C
ASE MODEL

The relevant actors are added to the model. For each user task a corresponding use case is identified and
described, stating its primary
course and alternate courses, and all possible exceptions.

The level of detail for each use case description should be such that it is understandable for the Business. It
is a refinement of the requirements, focusing on the interaction between system and actors and giving
details on the main validations. Use case
diagrams are part of the
system

documentation; they will not be
updated during maintenance.

Try to avoid introducing use cases corresponding to operations of components. In general, whenever an
additional use case description contains interactions with a u
ser, it is indeed a use case. If such a description
does not mention interactions at all, but merely lists a number of automated tasks, it probably refers to an
operation that will be detailed in sequence diagrams.

It is not recommended to use ‘extends’ re
lations and ‘ternary’ relations in use case diagrams; this might
cause confusion on semantics. In practice, it is not necessary to use these techniques on global analysis
level.






Page
11

-

39


3.

D
EVELOP AN INITIAL BU
SINESS CLASS MODEL

From the use cases a business class
model is created, with the emphasis on an overall structure, rather than
on too much detail. The initial business class model focuses on the associations between business entities,
represented by classes.

Inheritance should only be used in case of
speciali
sation
,

to improve modularity and maintainability of the
system. The super class should be modelled as an abstract class, i.e. any objects must belong to one of its
subclasses.

4.

D
EVELOP INITIAL BUSIN
ESS SEQUENCE DIAGRAM
S

For each use case a sequence diagram

is made, representing the high level interaction between the business
classes involved. Refrain from detailing and adding implementation
-
specific aspects as much as possible.
During this task additional business classes might be discovered, as well as cha
nges to the use case model.
This task may introduce new operations to classes in the existing class model.

Modelling the flow or sequence of actions as described in the underlying use case is typically handled by
introducing a controller component. Control
ler component maintains the sequence of actions and state of
the application.

5.

C
OMPLETE THE BUSINESS

CLASS MODEL FOR THE
G
LOBAL
A
NALYSIS

Complete the class model with class descriptions, logical attributes and operations from the business
sequence diagrams.


Operations are described by stating (at least) their purpose. Note that when an operation is part of a
component interface (to be determined in the next task), its signature and all pairs of pre and post conditions
will also be defined. An Excel spreadsh
eet may be used for larger sets of pre and post condition pairs.

6.

I
DENTIFY BUSINESS COM
PONENTS AND DETAIL T
HE INTERFACES

The business classes are clustered into logical components. Each component is described in terms of
contained business classes. Each ext
ernally visible operation is formally defined with detailed descriptions
of its signature and all pairs of pre and post conditions.

Component specifications are the starting point for defining the test scripts of the System Test.

At this stage, support ut
ility package may also be created to contain classes, the objects of which are passed
between components as parameters.

In general, component interfaces are not discussed with the user, because of the level of detail and the types
of expertise required. Fo
r this purpose the prototype is used.

7.

C
REATE AN INITIAL PRO
TOYPE

A prototype is developed to enhance the understanding of the system to be built. It is intended for the
Business and the project teams performing the Global and Detailed Analysis. The prototy
pe is used to
present the ‘look and feel’ of the system, to assist in acquiring a more thorough understanding of its
requirements, terminology and functionality, and to be able to discuss the functionality of the system with
Business. Note that although th
e Business should be perfectly able to understand use case diagrams, this
may not be the case for business sequence diagrams and class models. The initial prototype may be
elaborated during the Detailed Analysis phase.

The prototype consists of screen layo
uts, screen flows, and the main validations, thus visualising the
application. Note, however, that the prototype is not the application itself. It is
not
intended as the starting
point of development, but merely serves as a reference. For prototyping, seve
ral easy
-
to
-
use tools may be
used, such as Word, Front Page, Visual Basic or simply html prototypes.

Figure
2

depicts the tasks, indicated by their tas
k number, that are performed during the Global Analysis,
together with the resulting deliverables.




Page
12

-

39


1
Logical
architecture
2
Use case
model
3
Business
class model
4
Business
sequence
diagrams
6
Components
and interfaces
5
Initial
prototype
7
7
0
Completed
business
process model
Test Basis for
System Test

Figure
2
: Tasks and deliverables of the Global Analysis phase

4.2.4

Deliverables



Completed business process
model



Use case model



Business class model



Sequence diagram per use case, focussing on business classes



Logical component specifications consisting of:



Contained business classes including logical attributes and operations



All published operations defined i
n terms of their signature and all pairs of pre and post conditions



Initial prototype



Test basis for Component and System Test

4.2.5

Review

Peer review has to be performed for each task. Process review is performed by QA. Component Management
performs product re
view on component descriptions.

4.3

Plan Logical Increments

4.3.1

Objective

In this activity, logical increments are identified. The identification of these increments should be influenced by
external factors, e.g. customer, dependencies. This work should be in cons
ultation with the customer. For
instance, if the customer wants an application to be delivered in two increments, first increment being an initial
version of the application and the second increment being the enhanced version of the application with added
functionality or features.

4.3.2

Input



Business Requirement



Solution Architecture deliverables



Global Analysis deliverables.

4.3.3

Tasks

Refer to Appendix C for a template of a Logical Increment Plan, which elaborates the tasks to be carried out in
this phase in much

detail. For an example of how to plan Logical Increment refer to Appendix A.




Page
13

-

39



1.

Develop Overall Increment Plan

4.3.4

Deliverables



Overall Increment Plan, consisting of a collection of use cases. Additionally, dependencies between
increments are indicated.

4.4

Deliver
ables Assessment

4.4.1

Objective

The deliverables from the Global Analysis phase are assessed based on the inputs of Global Analysis. If
required, feedback is provided to the team that performed the Global Analysis. The phase ends with a formal
acceptance of the

assessment.

4.4.2

Input



Global Analysis inputs



Global Analysis deliverables

4.4.3

Tasks

1.

Initial assessment of increment (by deliverables acceptance checklist)

2.

Study and evaluate deliverables of Global Analysis for completeness

3.

Update Project Work Plan/Microsoft
Project Plan by estimating required time and resources

4.

Prepare acceptance and review report

4.4.4

Deliverables



Assessment & review report/Deliverables



Update Project Work Plan

4.5

Detailed Analysis

4.5.1

Objective

This phase focuses on identifying user and data component
s required by the business components identified
during Global Analysis.

4.5.2

Input



Updated inputs of Global Analysis



Global Analysis deliverables

4.5.3

Tasks

Following are the tasks to be carried in Detail Analysis phase with their brief description. For further det
ails as
how to execute each task refer to the Guidelines to Execute CBD Process document [9].


1.

I
DENTIFY DATA COMPONE
NTS AND DETAIL THE I
NTERFACES

The business components that were defined during the Global Analysis will have to make use of data
services to

cater for persistency. Data components are to be regarded as components that encapsulate the
various ways of accessing an underlying database.




Page
14

-

39


The data components that are required to support the business components defined so far are identified.
These
components may be already available from Component Management. If this is not the case, they
have to be defined as components. Operations are described by stating (at least) their purpose. Note that
when an operation is part of a component interface (to be

determined in the next task), its signature and all
pairs of pre and post conditions will also be defined. An Excel spreadsheet may be used for larger sets of
pre and post condition pairs.

Component specifications are the starting point for defining the t
est scripts of the System Test.

2.

I
DENTIFY USER COMPONE
NTS AND DETAIL THE I
NTERFACES

Similar to the definition of the business and data components, user components are identified. The initial
screen designs that were part of the Global Analysis’ prototype ca
n be used for this. These screen designs
are detailed to such a level that they are understandable for the Design & Build phase. The detailed screens
are incorporated into the initial prototype.

The resulting user component model consists of a number of us
er interfaces. During this task additional
dialogue screens and windows may be found. Also, additional information may be required from the user.

Component specifications are the starting point for defining the test scripts of the System Test.

3.

E
NHANCE BUSI
NESS AND CONTROLLER
COMPONENTS

The business components are detailed revealing complete class descriptions, including all attributes and
operations resulted during the identification of data and user components.

4.

E
NHANCE BUSINESS SEQU
ENCE DIAGRAMS

Now that t
he descriptions of user components, business components and data components are complete, the
interaction of all classes is finalised. The result is a complete set of sequence diagrams.

5.

C
REATE A STATE MODEL

During the analysis stages state diagrams are va
luable to assure the completeness of the analysis, especially
with respect to coverage of all events. They are intended for checking purposes and are only relevant if a
significant part of an object’s life cycle is to be covered by the system.

Figure
3

depicts the tasks and deliverables of the Detailed Analysis phase.


1
List of data
services
2
User services
model
3
Enhanced object
interaction model
4
Detailed busi
ness
class model
5
State
model
Detailed
prototype

Figure
3
: Tasks and deliverables
of the Detailed Analysis phase

4.5.4

Deliverables



List of required data components




Page
15

-

39




User components



Detailed prototype



Detailed business and controller components



Detailed sequence diagrams



State model with relevant state diagrams (optional)



Test cases for Data
and User Components

4.6

Plan Technical Increments

4.6.1

Objective

This activity focuses on partitioning of system and ordering the partitions in which the actual design and build
will take place. The partitions may be interdependent. For each application, there can
be zero or more logical
increments, and for each logical increment there can be one or more technical increments. Refer to Appendix D
for a template of a Technical Increment Plan.

4.6.2

Input



Detailed Analysis deliverables

4.6.3

Tasks

Refer to Appendix D for a templat
e of a Technical Increment Plan, which elaborates the tasks to be carried out
in this phase in much detail. For an example of how to plan Technical Increment refer to Appendix A.


1.

Refine the Logical Increment Plan into a detailed plan for the technical inc
rements within the current
logical increment.

4.6.4

Deliverables



Technical Increment Plan for the current logical increment.

4.7

Design & Build

4.7.1

Objective

The Design & Build phase concerns the elaboration of the analysis results (i.e. use case diagrams, sequence
diag
rams, class models and component model) and the actual realisation into code. As a starting point, every
logical component will have a technical equivalent, but for realisation additional classes may be added.

4.7.2

Input



Detailed Analysis deliverables



Updated
inputs of Detailed Analysis



Technical Increment Plan

4.7.3

Design

The design phase has two main goals:

1.

To prepare the analysis deliverables for build.

During design the necessary level of detail is added to
business model, sequence diagrams and state diagrams. I
n particular, design level classes are added
representing the technical solutions that can be mapped into code.

2.

To provide accurate documentation of the system.

The design deliverables can be thought of as a roadmap
into the system. Good quality documenta
tion is very important for maintenance. Additional class diagrams
and packages may be defined to provide proper navigation through the models.




Page
16

-

39


4.7.3.1

Tasks

Following are the tasks to be carried in Design phase with their brief description. For further details as

how to
execute each task refer to the Guidelines to Execute CBD Process document [9].


1.

M
AP TO
T
ECHNICAL
A
RCHITECTURE

Before being able to start with the design, a mapping is required that describes how the deliverables of the
detailed analysis are to be r
ealised within the technical architecture selected during the Solution
Architecture phase. Such a mapping is based on standards and guidelines from the Architecture Unit. Refer
to Appendix E for an example.

2.

O
PTIMISE CLASS MODELS

The analysis class diagram
s, i.e. business class model and user class model, are refined and extended by
applying abstraction and generalisation. This may involve adding classes and operations. Directions of
associations and/or aggregations between classes are also determined.

3.

D
ETA
IL AND EXPAND
O
BJECT SEQUENCE DIAGR
AMS

The analysis object sequence diagrams are detailed where needed. The lower level diagrams that connect to
high
-
level diagrams are further evolved. New responsibilities, discovered using delegation
1
, are assigned to
ne
w or existing classes.

While elaborating object interaction, new operations are added to the classes and new relations between
classes are discovered.

4.

A
PPLY PATTERNS

The class models are analysed for applicability of patterns that further optimise the mo
dels.

5.

O
RDER DATA COMPONENTS

The data components that were identified during the Detailed Analysis are either developed or obtained
from Data Management.

6.

M
AP TECHNICAL COMPONE
NTS ONTO PACKAGES

For each technical component (EJB, Servlet etc.), there should
be a separate package in Java.

4.7.3.2

Deliverables



Logical to technical component mapping



Optimised business class model



Optimised user components



Optimised sequence diagrams



Data components

Figure
4

depicts the tasks and deliverables of the Design phase.





1

When a task that needs to be performed is too complex to be handled entirely within one class, parts of it are
delegated

to other classes.




Page
17

-

39


2
Optimised business
class model
4
Data
services
5
Optimised user
services model
Technical architecture
mapping
1
Optimised sequence
diagrams
3

Figure
4
: Tasks and deliverables of the Design phase

4.7.4

Build

4.7.4.1

Tasks

Following are the

tasks to be carried in Build phase with their brief description. For further details as how to
execute each task refer to the Guidelines to Execute CBD Process document [9].


1.

M
AP PACKAGE STRUCTURE

Packages defined during design are mapped into Java code,
using the Java package concept, according to
the agreed naming conventions.

2.

M
AP STATIC MODEL
(
CLASSES
)

The classes are created in Java. Fields and methods are added. Relations between classes are mapped to
object references from one class to another.

3.

M
AP O
BJECT RELATIONS

References from a particular object to other objects are set, typically from initialise or constructor methods.

4.

C
REATE VISUAL CLASSES

The user interface classes are realised for use as a starting point for interacting with the business and
controller components.

5.

M
AP OBJECT SEQUENCE D
IAGRAMS TO ACTUAL PR
OGRAMMING CODE

The interaction between objects is added to the code, starting with the high level interaction. This involves
complete programming of many high level methods.

6.

C
ODE THE INCREMENT

FOR DESIGN
&

BUILD

Lower level interaction is added along with other missing code.

7.

E
NSURE TRACEABILITY

Amendments made during build are traced back to the Select design models. There should be a traceability
feature available to identify the changes made

during coding to be reflected in design.

8.

P
ERFORM
U
NIT
T
EST FOR EACH CLASS

Each class should be tested individually when developed to avoid any cumulative side effects in testing set
of classes.

9.

P
ERFORM
U
NIT
I
NTEGRATION
T
EST FOR CURRENT
T
ECHNICAL
I
NCREMEN
T

Each technical increment comprising of co
-
operating technical components and classes should be tested to
achieve the desired functionality. Driver programs may need to be written to test the technical increment.




Page
18

-

39


4.7.4.2

Deliverables



Application source code



Sourc
e code documentation



Deployment/Installation manual



User manual

Figure
5

depicts the tasks and deliverables of the Build phase.

1
Sources and
objects
3
Tested sources
and objects
2
Updated design
model
4
5
6
8
9
7

Figure
5
: Tasks and deliverables of the Build phase


4.8

Component Test

4.8.1

Objective

Compon
ent testing verifies whether the component fulfils the requirements set in the Component Specification.
This specification contains information on all component aspects, including performance reliability, downward
compatibility, concurrent use and exceptio
n handling.
The development team typically executes this phase.

4.8.2

Input



Design & Build



Test Cases from Global and Detailed Analysis

4.8.3

Tasks

Following are the tasks to be carried in Component Test phase with their brief description. For further details as
how t
o execute each task refer to the Process and Procedures for CBD Testing at AAGITS [10].


1.

Create drivers and stubs

2.

Create test scripts

3.

Test components

4.8.4

Deliverables



Drivers and stubs



Tested Components



Test results




Page
19

-

39


4.9

Component Integration Test

4.9.1

Objective

The Component Integration Test phase is aimed at testing a
subsystem
, consisting of the range of components
(i.e. user, control, business and data components) that implement one specific use cases.

4.9.2

Tasks

Following are the tasks to be carried in Component
Integration Test phase with their brief description. For
further details as how to execute each task refer to the Process and Procedures for CBD Testing at AAGITS
[10].


1.

Create drivers and stubs

2.

Test subsystems

4.9.3

Deliverables



Drivers and stubs



Tested subsyst
ems



Test Results

4.10

Component Acceptance

4.10.1

Objective

The Component Acceptance phase formally tests the components received from Design & Build. The
Component Test phase should deliver the necessary drivers and stubs. The test basis comes directly from the
Globa
l Analysis phase.

4.10.2

Input



Tested components



Test scripts



Test results

4.10.3

Tasks

Following are the tasks to be carried in Component Acceptance Test phase with their brief description. For
further details as how to execute each task refer to the Process and
Procedures for CBD Testing at AAGITS
[10].


1.

Test components using drivers and stubs

4.10.4

Deliverables



Accepted components that can be placed under Component Management



Test Results

4.11

Assembly

4.11.1

Objective

In the assembly phase the components associated with an appl
ication (release) are assembled. This application
will be offered to the System Test.




Page
20

-

39


4.11.2

Tasks

Following are the tasks to be carried in Assembly phase with their brief description. For further details as how to
execute each task refer to the Process and Proc
edures for CBD Testing at AAGITS [10].


1.

Assemble the application into an executable program.

2.

Assembly Manual

4.11.3

Deliverables

1.

Deployable program.

2.

Documentation

3.

Assembly Manual

4.

Source Code




Page
21

-

39


5

Appendices

5.1

Appendix A: Planning Logical and Technical Increments


Example


US4
US5
US1
US2
US3
Use case 1
Use case 2
Use case 3
Use case 4
Increment 1
Increment 2
Increment 3
Data Service Components (Pre-existing)
US1
Data Service
Component
US2
US3
Technical
Increment 1
Business
Components
Business
Components
Support
Utility
Package
Support
Utility
Package
Support
Utility
Packages
Technical
Increment 2
Controller
Component
Controller
Component

Figure
6
: planning logical and technical increments


an example scenario


After Global Analysis, the example project is split up into three logical increments by aggregating a number of
use cases per increment (phase
Pl
an Logical Increments
). Subsequently, the Detailed Analysis phase is executed
for each logical increment after which these increments are subdivided into technical increments (phase
Plan
Technical Increments
)
.

Increment number 2 is illustrated in more deta
il in
Figure
6
. This logical increment is
decomposed into two technical increments
.

Technical increment 1 encompasses the design and build of user
ser
vices (US1, US2 and US3). A controller component for use case 2 is also developed during this technical
increment. Additionally, some business components, a data service component and part of the Support Utility
Packages are also designed and built during
this technical increment. A similar development plan is made for
the second technical increment.

Technical incremental planning does not necessarily enforce component development to be restricted against the
corresponding use cases only. Hence, a particula
r user, business or data service component against use case 3
may also be designed and built during the execution of technical increment 1.




Page
22

-

39


5.2

Appendix B: Checklists


Global Analysis

P
ROJECT
N
AME
:


D
ATE
:


D
EFINE
/C
ONFIRM THE
I
NITIAL
L
OGICAL
A
RCHITECTURE

1.




yes



no



n.a.

The initial logical architecture has been defined.

I
DENTIFY THE
A
CTORS AND
D
EVELOP THE
U
SE
C
ASE
M
ODEL

2.




yes



no



n.a.

The actors have been identified and added to the use case diagrams.

3.




yes



no



n.a.

A description is provided for every actor.

4.




yes



no



n.a.

A use case has been created against each user task in the Solution
Architecture or requirement document.

5.




yes



no



n.a.

Every use case involves user interaction, which is mentioned in its
description.

6.




yes



no



n.a.

Every use case description
contains its primary course and all possible
alternate courses.

7.




yes



no



n.a.

Every use case description contains all possible exceptions.

8.




yes



no



n.a.

The level of detail of each use case description is understandable.

D
EVELOP AN
I
NITIAL
B
USINESS
C
LASS
M
ODEL

9.




yes



no



n.a.

An initial business class model has been created.

D
EVELOP
I
NITIAL
B
USINESS
S
EQUENCE
D
IAGRAMS

10.




yes



no



n.a.

Every use case is accompanied by a corresponding sequence diagram.

11.




yes



no



n.a.

Every sequence diagram represents the high
level interactions between the
business classes, without containing implementation
-
specific aspects.

12.




yes



no



n.a.

The controller components for the application have been identified along
with their interface operations including their signature and pre
and post
conditions.

13.




yes



no



n.a.

Every sequence diagram that corresponds to a use case specifies user
interaction by drawing events from the user to a controller class object
(representing controller component).

C
OMPLETE THE
B
USINESS
C
LASS
M
ODEL FOR THE

G
LOBAL
A
NALYSIS

14.




yes



no



n.a.

All additional classes that were identified in the initial business sequence
diagrams are present in the business class model.

15.




yes



no



n.a.

Every business class that has been identified so far is provided with a class
description.

16.




yes



no



n.a.

Every class is defined by its logical attributes and operations.

17.




yes



no



n.a.

For every attribute and operation a description is provided stating its
purpose.

18.




yes



no



n.a.

The signature of all operations of each class should be

complete.

IDENTIFY

BUSINESS

C
OMPONENTS AND
D
ETAIL THE
I
NTERFACES




Page
23

-

39


19.




yes



no



n.a.

All business classes have been clustered into logical components.

20.




yes



no



n.a.

For each identified component, the component specification is complete. It
includes

-

Component
name

-

Interface Specification (refer to Appendix G)

21.




yes



no



n.a.

Pre and post conditions have been provided for each interface operation.

22.




yes



no



n.a.

Test cases for components have been prepared following the template []

C
REATE
A
N
I
NITIAL
P
ROTOTYPE

23.




yes



no



n.a.

Initial prototype has been created and approved by the client.

P
EER
R
EVIEW

24.




yes



no



n.a.

A peer review has been performed for the Global Analysis deliverables.

C
OMMENTS


























Page
24

-

39


Plan Logical Increments

P
ROJECT
N
AME
:


D
ATE
:


D
EVELOP
O
VERALL
I
NCREMENT
P
LAN

1.




yes



no



n.a.

The contents of each increment are described in terms of contained use
cases, business classes and logical components.

2.




yes



no



n.a.

Any dependencies between logical increments, if any, are clearly specified.

3.




yes



no



n.a.

All increments that are to be developed in parallel are mentioned with
respective time
-
scales.

C
OMMENTS
































Page
25

-

39


Deliverables Assessment

P
ROJECT
N
AME
:


D
ATE
:


A
CCEPT
D
ELIVERABLES FROM
G
LOBAL
A
NALYSIS

1.




yes



no



n.a.

An
initial assessment of the assigned increment has been made.

2.




yes



no



n.a.

The contents of the global analysis deliverables have been studied and
evaluated.

3.




yes



no



n.a.

Refinements of the estimates on the time and resources required have been
made.

4.




yes



no



n.a.

The deliverables from the global analysis for the current logical increment
have been formally accepted.

C
OMMENTS




























Detailed Analysis

P
ROJECT
N
AME
:


D
ATE
:





Page
26

-

39


G
ENERAL

1.




yes



no



n.a.

The detailed analysis model focuses on
logical rather than technical aspects.

I
DENTIFY
D
ATA
C
OMPONENTS AND
D
ETAIL THE
I
NTERFACES

2.




yes



no



n.a.

All the pre
-
existing data components have been identified.

3.




yes



no



n.a.

All data components to be newly developed have been defined.

4.




yes



no



n.a.

All

data components have been identified. For each identified data
component, the component specification is complete. It includes

-

Component name

-

Interface Specification (refer to Appendix G)

I
DENTIFY
U
SER
C
OMPONENTS AND
D
ETAIL THE
I
NTERFACES

5.




yes



no



n.a.

All user components have been identified. For each identified user
component, the component specification is complete. It includes

-

Component name

-

Interface Specification (refer to Appendix G)

6.




yes



no



n.a.

The relationship between the user components and
the controller
components are specified.

E
NHANCE
B
USINESS AND
C
ONTROLLER
C
OMPONENTS

7.




yes



no



n.a.

The business class model has been detailed in terms of class description,
including all attributes and operations.

E
NHANCE
B
USINESS
S
EQUENCE
D
IAGRAMS

8.




yes



no



n.a.

Every sequence diagram is sufficiently detailed to include all operations.

9.




yes



no



n.a.

Every class is being referred to by at least one sequence diagram.

D
ETAIL THE
P
ROTOTYPE

10.




yes



no



n.a.

The prototype from the Global Analysis has been
detailed.

11.




yes



no



n.a.

The detailed prototype can be used for the design and build phase.

12.




yes



no



n.a.

All user requirements with regard to screen layout are present in the detailed
prototype.

S
TATE
M
ODEL

13.




yes



no



n.a.

State model diagrams are provided,

for those objects that can have different
states within the system.

P
EER
R
EVIEW

14.




yes



no



n.a.

A peer review has been performed for the Detailed Analysis deliverables.

C
OMMENTS











Page
27

-

39








Page
28

-

39


Design and Build

P
ROJECT
N
AME
:


D
ATE
:


D
ESIGN

1.



yes



no



n.a.

Mapping to technical architecture has been done based on the template (refer
to appendix E)

2.



yes



no



n.a.

Component specifications for business, user and data components have been
completed (refer to appendix G).

3.



yes



no



n.a.

Newly identified classes,

if any, have been incorporated in class model.

BUILD

4.



yes



no



n.a.

Packages, in Java, are created following the Build guidelines [9] and naming
conventions [2].

5.



yes



no



n.a.

Class model has been mapped to Java code following the Build guidelines
[9].

C
OMMENTS






















Page
29

-

39


5.3

Appendix C: Logical Increment Plan Template


Logical Increment Plan

P
ROJECT
N
AME
:

Credit Risk Management (CRM)

D
ATE
:

21
-
01
-
2000


I
NCREMENT
1

I
NCREMENT
2

I
NCREMENT
3

Use Cases

Introduce Facility (basic)

Authorise
Facility

Remove Facility

Update Facility

Introduce Facility
(additional functionality)






Controller Layer

IntroduceFacilityController

AuthorizeFacilityController

RemoveFacilityController

UpdateFacilityController





IntroduceFacilityController
(additional functionality)


Business Layer

CreditFacilities

CustomerServices

CollateralServices

AccountServices

CurrencyServices

BranchServices

StaffServices

BranchProductServices

CreditFacilities

CustomerServices

CollateralServices

AccountServices

CurrencyServices

BranchServices

StaffServices

BranchProductServices









Description

Increment 1 consists of the
main part of the
application’s functionality.





Increment 2 completes the
functionality of the
application.









D
EPENDENCIES

Increment 1 is not dependent on any other increment.

Increment 2 is dependent on increment 1.






B
UILD
P
LAN

Increment 2 is started after completion of increment 1.










Page
30

-

39


5.4

Appendix D: Technical Increment Plan Template


Technical Increment Plan

P
ROJECT
N
AME
:

Credit Risk Management (CRM)

L
OGICAL
I
NCREMENT
:

1

D
ATE
:

18
-
02
-
2000


I
NCREMENT
1

I
NCREMENT
2

I
NCREMENT
3

Use Cases

<none>

Introduce Facility

Authorise Facility

Remove Facility

Update Facility

Presentation Layer







FacilityCharacteristicsScreen

ProductGroupScreen

FacilityHeaderScreen

GetCustomerNumberScreen

CollateralRequirementScreen

CollateralShareGroupScreen

CollateralDataScreen

CollateralScreen

GetCustomerAndFacilityIdScreen

FacilityCharacteristicsScreen

ProductGroupScreen

FacilityHeaderScreen

GetCustomerNumberScreen

CollateralRequirementScreen

CollateralShareGroupScreen

CollateralDataScreen

CollateralScreen

Controller Layer


IntroduceFacilityController







AuthorizeFacilityController

RemoveFacilityController

UpdateFacilityController

Business Layer


CreditFacilities

CustomerServices

CollateralServices

AccountServices

CurrencyServices

BranchServices

StaffServices

BranchProductServices

CreditFacilities

CustomerServices

CollateralServices

AccountServices

CurrencyServices

BranchServices

StaffServices

BranchProductServices

Data Layer

CZFG0410 Credit Facility

CMFQ0110 Contract (SMART)

CZFC0310 Party

CZFA0310 Currency SWIFT

CZFC1410 Customer

CZFG0610 Collateral Limit



Description

Increment 1 consists of a
number of Java Server
Objects in the Data Layer.
These objects will be
accessed through RMI from
the business layer.

Parts of the business (EJBs),
controller (Routers) and
presentation (servlets) layer
are developed in this
increment.

The remainder of the business
(EJBs), controller (Routers)
and presentation (servlets)
layer is developed in this
increment.

D
EPENDENCI
ES

Increment 1 is not dependent on any other increment.

Increment 2 is partially dependent on increment 1.

Increment 3 is dependent on increments 1 and 2.

B
UILD
P
LAN

Increments 1 and 2 are developed in parallel. Increment 3 is started after completion of
increments 1 and 2.





Page
31

-

39


5.5

Appendix E: Mapping to Technical Architecture Example


Component

Layer

Realisation

Deployment environment

FacilityCharacteristicsScreen

P

Visual servlet

NT WebSphere Application server

ProductGroupScreen

P

Visual servlet

NT
WebSphere Application server

FacilityHeaderScreen

P

Visual servlet

NT WebSphere Application server

GetCustomerNumberScreen

P

Visual servlet

NT WebSphere Application server

CollateralRequirementScreen

P

Visual servlet

NT WebSphere Application server

CollateralShareGroupScreen

P

Visual servlet

NT WebSphere Application server

CollateralDataScreen

P

Visual servlet

NT WebSphere Application server

CollateralScreen

P

Visual servlet

NT WebSphere Application server

IntroduceFacilityController

C

Non visual
servlet

NT WebSphere Application server

CreditFacilities

B

EJB (Session Bean)

NT WebSphere Application server

CustomerServices

B

EJB (Session Bean)

NT WebSphere Application server

CollateralServices

B

EJB (Session Bean)

NT WebSphere Application server

AccountServices

B

EJB (Session Bean)

NT WebSphere Application server

CurrencyServices

B

EJB (Session Bean)

NT WebSphere Application server

BranchServices

B

EJB (Session Bean)

NT WebSphere Application server

StaffServices

B

EJB (Session Bean)

NT
WebSphere Application server

BranchProductServices

B

EJB (Session Bean)

NT WebSphere Application server

CZFG0410


Credit Facility

D

Java Server Object

AS/400

CZFG0410


Credit Facility

D

EJB (Session Bean)

NT WebSphere Application server

CMFQ0310


Deposit Contract

D

Java Server Object

AS/400

CMFQ0310


Deposit Contract

D

EJB (Session Bean)

NT WebSphere Application server




Page
32

-

39


5.6


Appendix F: Using Select Enterprise

When deleting a use case that is no longer appropriate from a use case diagram, you should

first delete the
relationship (‘uses’ or ‘extends’) and then the use case. When you delete the use case and then the relationship,
the relationship remains registered within the model and still appears in reports. In this case, you will have to
delete the

relationship manually; Select does not currently have some kind of ‘recalculate model’ facility.

When developing the use case model during the Global Analysis one should try to avoid introducing additional
use cases that are essentially operations. In Sel
ect, it is possible to attach a sequence diagram to an operation as
well. Instead of introducing use cases that are not really use cases, this technique should be used.

The ‘architectural boundary’, indicated by a dotted vertical line, does not have real s
ignificance. It should
always reside between the user classes and the business classes of each sequence diagram.




Page
33

-

39


5.7


Appendix G: Terminology

Actor

An actor is anything that uses or interacts with the system. The system exists (or is being developed) purely a
nd
simply to support that interaction. Actors can be subdivided into different categories:



Role: people take on a role, then behave in a different way. Many different people can play a role, and
one person can play many different roles. Examples: staff
member, customer.



Organisation: a group acting in concert, which can be treated as a single entity. Example: account
management.



Systems and devices: software or hardware systems with which the system must communicate.
Examples: accounting package, ATM.

Us
e case

A use case is formally defined as ‘a behaviourally related sequence of interactions performed by an actor in a
dialogue with the system to provide some measurable value to the actor’.

Put in different words, a use case is one usage of the system, d
escribing the logical interactions and capturing
the required behaviour of the system and its final state. Use cases define how actors will interact with the
system. A use case describes a well
-
defined part of the functionality of an application, as provid
ed to the user.
The complete set of use cases describes the behaviour required of the system.

During the Global Analysis phase, each use case corresponds to exactly one user task (or elementary business
process).

Abstract use cases

When developing applica
tions with several use cases, it is normal to find use cases with similar descriptions. To
avoid redundancy and enhance reuse, the ‘uses’ association can show where part of a common sequence of
events have been abstracted out of a concrete use case, and is

now accessible by many concrete use cases. The
part of the use case extracted out is referred to as an
abstract use case
, because it will not be instantiated on its
own, but is meaningful only to describe parts shared among other use cases. Use cases that

are effectively
instantiated and used are referred to as being
concrete use cases
. In Figure 7, Select Loan Type is an abstract use
case that is shared by the concrete use cases Introduce New Loan and Introduce Existing Loan.

Experience shows that it make
s sense to wait with identifying abstract use cases until a number of concrete use
cases have been described. Abstract use cases should evolve from concrete use cases, not the other way around.

Both abstract and concrete use cases will have associated sequ
ence diagrams[5].

Select Loan
Type
Introduce
New Loan
Introduce
Existing Loan
uses
uses

Figure
7
: abstract use case


Object




Page
34

-

39


An object is something tangible, something that can be seen or touched or felt, or something that can be alluded
to, conceptualised, thought about.

Ob
jects are the things that are going to be created in the running software, and they are going to communicate
with each other. In fact, that should be all the software is; a coherent mass of communicating objects, with new
ones being created, old ones being

deleted, and existing ones carrying out operations.

The major reason for having objects is so that they can do things. Object technology decomposes a system
entirely into objects; all the interactions of the system with the outside world and all the inter
nal computations of
the system must be carried out in the operations of objects. There are no other places to put functionality.

Class

A class is a
definition

or
template

for objects, which specifies how all objects in the class behave, and what
structure
they have and the operations that can be performed on the object. A
class definition

specifies the
operations and attributes for all
instances

of the class.

Service

A unit of functionality, that is implemented as an operation by a component.

Pre and post
conditions

Describing operations in terms of pre conditions (the state before an operation takes place) and post conditions
(the state after the operation has concluded) is a very useful standard way of expressing behaviour without
specifying a design. It
gives the ‘what’ not the ‘how’.

As example consider an operation that adds a member to an existing set of members. It may be specified as
follows:

addMember(
in

aPerson)

pre: the current set of members does not contain aPerson

post: the current set of membe
rs now contains aPerson

(Logical) Component

An encapsulated piece of functionality, small enough to create and maintain, big enough to deploy and support,
and only accessible via its standard interfaces.

In general, three perspectives apply to the definiti
on of a component:

1.

Package perspective: a component is a unit of functionality.

2.

Service perspective: a component is a provider of services, accessible through its interfaces.

3.

Integrity perspective: a component is an encapsulated unit that is independent of

the implementations of
other components.

A logical component can be a user, controller, business, or data component (
Figure
8
).




Page
35

-

39


Credit Facility
Maintenance
Services
Credit Facility
Reporting
Services
Credit Facility
Recording
Credit Facility
Authorization
Credit Facility
Reporting
Account
Services
Customer
Services
Credit Facility
Services
Account Data
Services
Customer
Data Services
Credit Facility
Data Services
Shielding Data
Services
Shielding
Services
User
Services
Business
Services
Data
Services
Business
Controller
Services

Figure
8
: logical component types



User Component

A unit of functionality that handles the presentation of information to the environment and takes care of
receiving input from the environment. It does not contain any business logic.

As an example, a user service might consist of a user interface class
that corresponds to a screen, having no
information about the navigation scheme (which controls the flow of screens).

Controller Component

A controller component is responsible for handling the navigation among screens (user control), maintaining the
state

of the application, and performing the sequence of operations (business control). Since these kinds of
components contain business logic, they reside within the business layer.

Business Component

A unit of functionality that represents part of the busines
s behaviour of an application. It typically provides a set
of business services to other components.

Data Component

A unit of functionality that makes data from the database available to other services. It usually has SQL
-
like
functionality, without functi
ons like sum and count, but preferably with existential quantifiers. Its functionality
should be realisable via standard operations of the DBMS.

Technical Component

A unit of software with a well
-
defined interface that has been created to realise a logical

component.

It should be designed in such a way that it can be realised based on the specifications of a standard component
model (e.g. Enterprise Java Beans, Microsoft’s Component Object Model etc.)

Support Utility Package




Page
36

-

39


A Support Utility Package (SUP)

is a package that contains the classes that are shared among different
components. Instead of defining these classes in each of the components repeatedly, they are put into a shared
package. A designer should try his best to reduce the number of shared cl
asses among components as it
increases the coupling between components. SUPs should only be used in inevitable circumstances.
Furthermore, there are different SUPs for data, business and presentation layers.

Logical Increment

Logical increment is part of
functionality agreed upon in consultation with the Business to be delivered
independently. For example, in customer search module, the customer can be searched by party number and
account number as the first increment. In the second increment, the customer

can also be searched by customer
name.

A unit of development that corresponds to a set of use cases, and is defined in terms of these use cases with their
corresponding sequence diagrams and business services involved, resulting from a particular Global A
nalysis
phase.

A logical
increment

should not be regarded as a separate part of functionality of the application that is being
built. It is a way of dividing (in some logical manner) the work that has to be done after the global analysis
phase into one or

more manageable chunks, i.e. into several sets of components. Each component will be tested
in a specific component test.

Note that while
identifying

an increment the user services are not mentioned in any place. The user services are
defined during the
detailed analysis phase.

Technical Increment

A unit of work in which Design and Build activities are done that correspond to a subset of components that
resulted from analysis within a logical increment. Technical increments belonging to the same logical i
ncrement
may be independent, but this is not mandatory. They serve merely as a means to divide the work at hand among
several groups of resources available over several periods in time.

Component Management

Component Management is a group that manages all
the components developed in an organisation.

This group has following responsibilities:



Management of components in a shared repository



Identification of common areas of reuse among business applications



Co
-
ordination with projects to define and build reus
able components

Data Management

Data Management is a group that manages a set of data services for any particular database. Ideally, there
should be one data management group in an organisation to provide support for all the underlying database
technologies.

Architecture Unit

The architecture unit is responsible for identifying and discussing the issues related to existing architecture,
identification of new technological areas that could have any impact on development unit, support for external
architectures and defining focus areas for each liaison architect.


Test Basis

All documents from which the requirements of an information system can be inferred. The documentation on
which test is based. If a document can only be amended by way of the for
mal amendment procedure, the test
basis is called a fixed test basis.




Page
37

-

39


Test Script

The succession of co
-
ordinated actions and checks relating to physical test cases including the order in which
they are to be executed. A description of how testing is to pro
ceed.

Peer Review

It is an immediate review by the peer, but the person actually doing the work has provision whether to act upon
the feedback or not.

Product Review

This review is performed usually on relatively larger unit after longer intervals and is i
ncluded in the project
work plan. The team responsible for this review can be comprised of more than one person. At the end of the
review, a report has to be produced.

Process Review

This review is usually performed at the end of a phase. At the end of the

review, a report has to be produced.
During the review it has to be made sure that all the use cases have been reviewed.

CITA

Corporate Information Technology Architecture (CITA), a project to provide guidelines for standard
Component Based Development &
Architecture on a corporate level to build a more flexible IT environment
throughout the ABN AMRO Organisation.

Attribute

An element of data contained in an object, as specified within the object’s class.

Operation

It is a unit of work that can be requeste
d from an object to perform a specific function. It operates on its data and
represents the behaviour of the class.

Package

A general purpose mechanism for organising elements into groups. In Java, it is defined as a grouping that can
contain classes and i
nterfaces.

Object Relation

It defines how the objects are related to each other, e.g. through inheritance, aggregation, and association. These
relationships are Unified Modelling Language (UML) specific.

Business

Business is the party that finalises the bu
siness requirements and structures them into a standard format.

Business Site

The Business resides at the Business Site.

Customer

Customer is an organisation that gives project to the Development Team. It is basically an interface between the
Business and
the Development team providing the planning for the project and detailing the business
requirements.

Customer Site

The Customer resides at the Customer Site.

Development Team

Development Team is the party that is responsible for the actual development of t
he project following CBD.

Development Site

The Development Team resides at the Development Site.




Page
38

-

39


Signature

Signature of an operation consists of its name, in/out parameter names and their data types, and return type.
Optionally, the signature of an operati
on can also specify exception(s) that can be thrown by that operation.

Component Specification

A component specification describes the external behaviour that is required of the component. It contains the
component name, its lookup procedure, version and r
elease number, component context and interface
specifications.

Component Context

It describes the environment in which the component is to execute and contains all the dependencies that this
component may have on other components.

Interface Specifications

Component interface specifications contains set of all the published operations of the component that can be
called by the client of the component along with the signature of those published operations. It can also have
exceptions that the operation can th
row.

Solution Architect

Solution Architects are members at customer site that interface between business and development team to
prepare solution architecture document based on its template [7].






Page
39

-

39


5.8

Appendix H: References

[1]

Embedding CBD within DI & AAGITS
, version 1.1, 21 January 2000.

[2]

JAVA Coding Standards, version 1.0, 29 December 1999.

[3]

C
ORPORATE
IT

A
RCHITECTURE
(CITA):

Deploying CITA CBD into DI
-
Pakistan
, version 0.3, 23
rd

September 1999.

[4]

Development Pipeline
-

Processes and Procedures for
the CBD
,

version 0.2, 24
th

September 1999.

[5]

QA

T
RAINING
: Object
-
Oriented Analysis and Design using the UML


Course Material, OOUFM1
v1.7, 1999.

[6]

Project Work Plan (PWP) template, version

[7]

Solution Architecture template

[8]

Multi
-
site Development

Model for AAGITS

[9]

Guidelines to Execute CBD Process

[10]

Process and Procedures for CBD Testing at AAGITS