CBD Project at the KDN

1
(No Transcript)
2
Outline

• 1. Introduction to CBD . 6
• 2. Typical CBD Process 7
• 3. 12 Steps to a better component architecture
  .. 30
• 4. Patterns for a better component architecture
  42
• 5. Defining better component interface
  specifications .. 56
• 6. Discussion .. 57

3
Background

• Component Based Development(CBD), Component Based
  Software Engineering(CBSE), Componentware.
• is based on a long history of work in modular
  system, structured design, and most recently in
  object-oriented system.
• extend above ideas.
• software construction is achieved through a
  component selection, evaluation, and assembly
  process.

4
What is a component?

• a software package which offers service through
  interfaces 1
• Component perspectives 2
• A package perspective (as a unit of delivery)
• focusing on identifying a set of elements which
  can be reused as a unit.
• A service perspective (as a provider of
  functionality)
• emphasizes the notion of a contract between the
  provider and the consumer of those services.
• An integrity perspective (as an encapsulation
  boundary)
• independent of the implementation of other
  components.
• these perspectives are not mutually exclusive

1 Peter Herzum and Oliver Sims Business
Components Factory A Comprehensive Overview of
Component-Based Development for the Enterprise,
John Wiley Sons, Incorporated, 1999 2 Alan
Brown, Sterling Software, White Paper, Building
Systems from Pieces with Component-Based Software
Engineering, 1999
5
Component Based Development

• is an approach to application development in
  which ready-made pieces of software are assembled
  together to enable the rapid construction of
  applications.
• An approach to software development in which all
  artifacts from executable code to interface
  specifications, architectures, and business
  models and scaling from complete applications
  and systems down to small parts can be built by
  assembling, adapting, and writing together
  existing components into a variety of
  configurations. 3
• General CBD approach 4
• decide on the scope of the application to be
  developed
• specify the components that will form the
  application
• acquire, reuse, or build the component
  implementations and
• assemble, test, and field the application

3 D'Souza, D.F., and A.C. Wills, "Object,
Components, and Frameworks with UML The
Catalysis Approach", Addison-Wesley, 1998 4
Alan Brown, Moving form Components to CBD
Supporting distributed computing paradigms,
Component Strategies, April 1999
6
Simplified CBD Process

• Process consists of twin routes or tracks that
  have interactions between each other.
• Iterative, Incremental, Parallel

Source CBD Express by John Dodd John
Cheesman, Chertsey Lab, CA, 1999
7
Twelve Steps to a Better Component Architecture

• An architecture is needed early in the project,
  so that
• costs can be estimated,
• resources can be organized,
• component purchased option can be investigated,
• developer get a good overview of what they are
  building,
• well-formed architecture is needed for good
  components

8
Component Modeling Step

• the steps of the process are classified as
• structure- or
• behavior-focused,
• and have been layered into stages.
• They are numbered in the order they are generally
  tackled.
• In practice, some steps may need to be repeated
  
• due to changing requirements,
• or because development occurs in increments,
• or due to errors found down the line.

Stage
Structure
Behavior
Requirements
1.High Level Requirements
3. Use Cases
2. Concept Model
4. Use Case Steps
Analysis
5. Business Type Model
6.Transactions
7. Secondary Use Cases
Architecture
8. Interface Responsibility
11. Operation Interaction
9. Interface Dependency
12. Operation Definition
10. Component Architecture
Design
Specification
15. Refined Component
13. Interface Type Model
Architecture
14. Pre Post Conditions
9
UML Diagrams

• A type diagram is a special form of class
  diagram, in which all the classes are types.
  That is, they are conceptual or specification
  constructs, not programming language constructs.
• An interface diagram is another special form of
  class diagram

1 High-Level Requirements
3 Use Case Diagram
4 Use Case Step Diagrams
2 Business Concept Model
Use Case Diagram
Sequence
Diagram
Type Diagram
6 Identify Transactions
5 Business Type Model
7 Find Secondary Use Cases
8 Interface Responsibility Model
11 Operation Interaction Diagrams
9 Interface Dependency Model
12 Operation Definition
10 Component Architecture Design
Operation
Component Diagram
Properties
Interface Diagram
15 Refined Component
13 Interface Type Modeling
Architecture
14 Pre/Post Condition Writing
10
Step 1 Capture High Level Requirements

• Limits on the project
• Record sponsors expectation
• Help decision-making
• H/L Requirements types
• Functional
• Technical
• Project Management
• requirements may be adjusted as the project
  progresses, But if they fluctuate a lot, or
  changed requirements are not communicated, the
  project is heading for disaster.

11
Step 2 Build a Concept Model

• Principal concepts within the project scope
• Each concept have a definition -gt dictionary of
  terms in domain
• is informal, should be built by the users
  themselves, may be activities or things

12
Step 3 Identify Use Case

• find all the key use cases
• users say they need to do with the system or
  become evident through workflow analysis of the
  business processes
• Decompose these use cases until they are atomic
• meaning they cant be decomposed further and
  still be genuine use cases.
• Genuine use cases should support some business
  task that achieves a useful business outcome
• there must always be a business event that is the
  motive for performing the use case
• Several actors may be involved in a use case, but
  only one of them initiates the use case
• ltltincludegtgt and ltltextendgtgt dependencies

13
Step 4 Define Use Case Steps 1/2

• Have a particular user interface style in mind
  when doing this (for example, web or block-mode
  screen or ATM),
• since this can considerably affect the number and
  nature of the exchanges.
• Dont try to design windows or web pages yet

Use Case Reserve Car
Initiator
Reserver
Goal To reserve a car, obtaining a reservation
code as evidence.
Frequency 400 per day.
Steps
0.
Reserver
(usually the customer) decides to reserve a car.
1.
Reserver
selects Period, From/To locations and Car Class
2. System Quotes Price
3.
Reserver
Accepts Quote
4.
Reserver
enters customer id
5. System records reservation and issues
reservation
nr
EXTENSIONS
3a. Declines quote
3a1 (see extension use case
QuoteDeclined
)
4a. Customer not registered
4a1 (see common use case
RegisterAsCustomer
)
VARIATIONS
Step 4.
Reserver
cannot remember the customer ID
Step 3.
Reserver
tries another car class
Step 1.
Reserver
will accept several car classes
14
Step 4 Sequence Diagram 2/2

• Depict the step of use case on a sequence diagram
• diagram shows actors, roles, steps, messages
  pairs,

15
Step 5 Prepare Business Type Model 1/2

• Derived from Concept model
• Formalize model
• define multiplicity, name the association
• include attribute, where known
• remove out of scope
• reduce redundancy, normalize
• seek generalization

16
Step 5 Distinguish ltltcoregtgt business type 2/2

• A core business type is one of the types of thing
  the business has to keep track of, to run its
  business efficiently, legally and successfully
• The business types of a company are relatively
  stable, making them a good foundation for
  enduring, shareable business components
• given ltltcoregtgt stereotype
• How to find the business type
• Types that have no mandatory associations to
  anything else are core business types
• Types that have a mandatory-one(1..1) association
  to another type are details of that type
• except where all the 1..1 associations are made
  to classifying (core business) types. A
  classifying type primarily groups or categorizes
  instances of another type.
• Core business types normally have an identifier
  that is just a single attribute -- often an
  artificial number or code invented by the
  organization.

17
Step 6 Identify Transactions

• Finds the business logic transactions that the
  server tier needs to support
• The sequence diagram that was drawn in Step 4 is
  used to tackle this topic
• after add Business Logic Layer to the sequence
  diagram, proceed as follows
• inspect each step of use case
• decide whether the exchange requires an operation
  of the business logic layer to be run
• given an operation is needed, first look to see
  if it has already been added to business logic
  layer
• if the operation cant be found, try to
  generalize or extend some existing operation.
  Its better to avoid building a lot of very
  similar operations
• if there is nothing to generalize, then define a
  new operation, to service the exchange
• some exchanges may utilize several operations
• draw the operation usage on the sequence diagram
• The business logic layer can then be reused with
  a different user interface style.
• The business logic layer is normally more
  enduring that the presentation layer.
• The data of the business logic layer needs to be
  shareable, while any presentation layer data is
  usually transient and for one user.

18
Step 7 Define Secondary Use Case

• The users, with some prompting by the analysts,
  should have identified most of the line of
  business use cases that support the primary aims
  of the application.
• You may obtain 2nd Use Cases from just business
  types.

19
Step 8 Decide Interface Responsibility 1/3

• Now, we already has
• summary of the required business logic from
  transactions in Step 6.
• summary of the data that needs to be stored from
  business types in Step 5.
• And then, the project will propose a set of the
  business components
• To achieve this, the process first identifies the
  interfaces that the components will support, and
  will decide upon the components themselves in a
  later step.
• here are main action used to identify interfaces
  and decide their responsibilities
• begin with copy of the business type model
• add one interface for each core business type
• add a composition association between the
  interface and core type
• the interface is also responsible for all the
  detailing types of the core business types
• Consider each cross-interface association

20
Step 8 Resolve cross-interface assoc. problem
2/3
ltltinterface typegtgt
ltltinterface typegtgt
ltlt typegtgt
ltlt typegtgt
ltlt typegtgt
1
2
C
B
A
ltlt typegtgt
This is a
cross-interface association
EXAMPLE
D

• Decide whether to provide navigability, just one
  or both or none
• Both direction has an updating overhead, so
  architects often prefer to support navigability
  in just one direction
• Some proposed rule that decide navigable
  direction is

0 ..
1 ..
ltlt typegtgt
ltlt typegtgt
B
A
0 ..
0 .. 1
ltlt typegtgt
ltlt typegtgt
B
A
1 ..
1 .. 1
ltlt typegtgt
ltlt typegtgt
B
A
21
Step 8 Interface Responsibility Model 3/3
22
Step 9 Determine Interface Dependencies 1/3

• Investigate the usage dependencies between
  interfaces
• derived from Interface Responsibility Diagram,
• and Operation Interactions
• Goal is reducing component dependencies. Achieved
  by
• reducing interface dependencies
• assigning group of interfaces
• Draw interface dependency diagram
• At this point, components need to be proposed

23
Step 9 Interface Dependency Diagram 2/3

• two significant architecture decision need
• Architecture pattern
• Allow cyclic network
• Allow acyclic hierarchical
• Independent of one another radial
• Include an application component

24
Step 9 Step of Interface Dependency Modeling
3/3

• Decide on architectural style, which might
  involve introducing an application component, and
  its interfaces.
• Assign each transactional operation of the
  Business Logic Layer (see step 6) to the most
  appropriate interface.
• Complete the interface responsibility diagram
  (IRD). Document which interface is responsible
  for the integrity of each cross-interface
  association.
• Draw the initial interface dependency diagram,
  deriving the dependencies from what is shown in
  the IRD where you can navigate from A to B, then
  assume the interface managing A will depend on
  the interface managing B.
• Investigate the dependencies between the
  interfaces. See if they can be reduced.
• Identify a set of tentative components and
  examine their dependencies. Draw the component
  architecture diagram as described in Step 11.
• Work on both diagrams, aiming to reduce the
  dependencies and achieve the architectural
  objectives defined earlier.

25
Step 10. Prepare Component Specification
Architecture 1/2

• Prepare the component specification architecture
  diagram for the application, depicting
• proposed components
• interfaces offered by each component
• interfaces required by each component
• dependencies can be derived from the interface
  dependency diagram
• Say interface IA depends on interface IB in the
  Interface Dependency Diagram. And Component CA
  offers IA and component CB offers IB. Then the
  architecture diagram should depict that CA
  depends on IB.)
• As mentioned in the previous step, the component
  specification diagram and interface dependency
  diagram, need to be developed in parallel

26
Step 10. Component Diagram 2/2

• IOptionMgr and ICarClassMgr are offered by the
  same component as ICarMgr, partly on account of
  their small size, but also owing to their strong
  dependencies.
• An acyclic dependency was removed by moving
  allCarsAtLocation( ) from ILocationMgr to ICarMgr

ltlt
nonComponent
gtgt
PresentationLayer
IRentalMgr
ltlt
componentSpecification
gtgt
RentalsComponent
ltlt
componentSpecification
gtgt
ICarMgr
IOptionMgr
ICarClassMgr
DriversComponent
IDriverMgr
ltlt
componentSpecification
gtgt
CarAdminComponent
ILocationMgr
ltlt
componentSpecification
gtgt
LocationsComponent
27
Step 11 Specify Operation Interactions

• An operation often needs to call other
  operations, of the same or different interfaces,
  in order to accomplish its work
• To help figure out and document these calls,
  sequence diagrams of operations can be drawn

Sequence Diagram for calculateRentalCost()
28
Step 12 Operation Definition

• As the sequence diagram are developed, new
  operation will be identified and allocated to the
  interface
• Now, provide each operation
• meaningful name
• parameters
• return value
• comments
• and any special features
• As the business components stabilize most of
  the operations having been found, and the
  signatures stable

29
Other steps

• Step 13 Interface type model
• Step 14 Pre Post Condition
• Step 15 Refined Component Architecture

We will take up the subject later
30
Break

• 12 Steps describes a process for preparing an
  initial component architecture
• and now we need better component architecture
• Main concept is
• finger-gained infrastructure component
• coarser-gained application component

31
PATTERNS FOR A BETTER COMPONENT ARCHITECTURE

• 12 Steps describes a process for preparing an
  initial component architecture
• and now we need better component architecture
• Main concept is
• finger-gained infrastructure component
• coarser-gained application component
• For this, five patterns are presented
• layered pattern
• three alternative style patterns
• storage sharing pattern
• human experience and judgement will play the
  largest part in the design of component
  architectures, but a systematic architecting
  process, and a knowledge of these patterns can
  also play a significant role, especially in
  organizations new to component-based development.

32
Components, Architectures and Patterns 1/2

• A component is a software building block
• offers its functionality through well-defined
  stable interface
• has state
• Client only access the components functionality
  and state through its interface
• encapsulated
• Are built to run in container software
• Provides standardized services such as activation
  and transaction management
• An architecture defines the big parts of a
  system, and how they fit together
• Big parts the architectural units are
  predominately software component
• In a component architecture, usage dependencies
  are defined between the architectural units

33
Components, Architectures and Patterns 2/2

• A pattern is a well-proven generic solution for a
  recurring design problem
• A pattern should always include these three
  elements
• Context The situation that give rise to a
  problem.
• Problem The recurring problem arising in that
  context. It identifies when the pattern should be
  applied.
• Solution The elements that make up the design,
  with their relationships, responsibilities and
  interactions. An abstract or generic description
  of the solution is supplied, which has to be
  tailored to the specific problem in hand.

• Example 1
• Context An organization decides to build their
  applications (business information systems) from
  software components.
• Problem After an initial set of business
  components have been identified, which other
  components are needed to complete the
  architecture?
• Solution The layered architecture prompts the
  architect to identify further components, and
  reduces the complexity of the architecture by
  introducing dependency restrictions based on
  layers.

• Example 2
• Context An organization decides to build their
  applications from software components. (So the
  context is the same as in example 1.)
• Problem How should the proposed components
  inter-connect one another, so that the technical
  goals are best achieved?
• Solution Select from one of three major
  architectural style patterns, which offer
  alternative technical qualities.

• Example 3
• Context An organization decides to build their
  applications from software components. (So the
  context is the same again.)
• Problem How should the persistent storage of
  the proposed components be organized, so that the
  power of a relational database management system
  is fully exploited?
• Solution Adopt the storage sharing pattern.

34
The Layered Architecture Pattern 1/3

• Architecture can be sub-divided into layers
• each layer contains components having a similar
  status or importance role
• a component depend upon another component in the
  same layer, or a lower layer. It cannot depend on
  a component from a higher layer

35
The Layered Architecture Pattern 2/3

• presentation layer not focus in this paper
• application layer
• presentation layer requests for business logic to
  the transactions of the application component
• application component then delegates the work to
  the business components in the next layer
• business component
• enable information to be kept about the instances
  of one or more business types,
• can offer analyses, searches and calculations
  about instances of one or more business types
• application-neutral
• business infrastructure component
• provide shared services to business component
• non-general business components
• technical infrastructure component
• arising due the use of computer systems, rather
  than because they perform facets of business
  processes

36
The Layered Architecture Pattern 3/3
 

• Example distinction between these layers is not
  always clear-cut

37
Architecture Style Patterns 1/2

• What kinds of dependency are to be permitted
  within a layer?
• mainly applied to the business component layer

• network
• least constraint
• cyclic

• hierarchical
• acyclic
• achieved by re-assigning operations, decompose
  operations, merge components

• radial
• Independent business components
• achieved by application component

38
Architecture Style Patterns 2/2
 

• advantage drawbacks of each style patterns

39
Storage Sharing Pattern 1/2

• Instead of a business component embedding its own
  data storage, all the business components, or
  some cluster of related business components, call
  a single, lower-level infrastructure component,
  that offers persistency service to the business
  component

40
Storage Sharing Pattern 2/2

• integrated database are realized
• it is possible to switch to a difference
  database design, without impacting the business
  component
• storage sharing component is accessed directly,
  bypassing the business components, then important
  business rules may not get applied
• OO principle that processing and rules about
  data should be encapsulated within the object
  that manages that data is strained

41
Experiences from some consultants
 
( indicates strongest, stronger - is weaker
and - - weakest o is middling)
42
DEFINING BETTER COMPONENT AND INTERFACE
SPECIFICATIONS

• Software component are delivered with a clear and
  full statement of their behavior
• The component user should only need to understand
  its external behavior its specification, not
  internal design!
• Behavior statements of component, Component
  Specification can and should be used to
• specify the component initially
• test the component
• explain the behavior to an architect
• explain component behavior to the user
• To describe component specification, two
  techniques are used
• interface type modeling (step 13)
• operation pre- and post-conditions (step 14)

43
Step 13 Interface Type Modeling 1/4

• Component has its state and offers its
  functionality through well-defined stable
  interface
• A description of what it remembers can be done
  using an interface type model
• for example, Address Book component provide
  interface, IAddressBookManager
• addAddress (inName, inType, inAddress, inPhone)
• Enables one new address and/or phone number to be
  recorded. The "inType" parameter takes the value
  H, W or T to indicate whether it is a home, work
  or temporary address.
• changeAddress (inName, inType, inAddress,
  inPhone)
• Enables the address or phone number to be changed
  for a given name/type.
• deleteAddress (inName, inType)
• Enables an entry to be deleted.
• getAddress (inName, inType, outAddressDetail)
• Returns the address and/or phone number for a
  given name/type.
• get Addresses (inName, outAddressDetail )
• Returns the addresses and/or phone numbers for a
  given name.
• listAddresses (inType, outAddressDetail )
• Returns all addresses of a particular type.

44
Step 13 Basic Expression for IAddressBookManager
2/4

• To make it quite clear this is not a programming
  class, we have added the stereotype ltltinterface
  typegtgt.
• The notation xY indicates that the (data) type
  of the attribute x is Y.
• So each element of the entry attribute is of type
  Address Detail.
• AddressDetail is a structure consisting of
  several attributes, so we have drawn this as a
  ltlttypegtgt shown on the right.

entry
AddressDetail
addAddress
(
inName
,
inType
,
inAddress
,
inPhone
)
changeAddress
(
inName
,
inType
,
inAddress
,
inPhone
)
deleteAddress
(
inName
,
inType
)
getAddress
(
inName
,
inType
,
outAddressDetail
)
get Addresses (
inName
,
outAddressDetail
)
listAddresses
(
inType
,
outAddressDetail
)
45
Step 13 IAddressBookManager in Catalysis 3/4

• Interface manage 0 to many Entries, each of which
  consist of a name, type, address and phone
  number.
• How it manage them is an implementation detail,
  which should not be relevant to the component
  user.

46
Step 13 IAddressBookManager in UML 4/4

• UML does not permit interfaces to own attributes.
  To support the interface type modeling concept,
  we make interface type a stereotype of the UML
  type concept, which is permitted to own
  attributes and operations. In UML, type is itself
  a standard stereotype of the very general UML
  class concept.

47
Invariants

• An invariant is a condition that must be met by
  all instances of a type or class
• a. A Warehouse can store many Stock Items,
• each Stock Item being of one Product
• b. allocated Stock lt available Stock
• c. identifier of Product is unique
• (can be used as an identifier for each Product)
• d. total Stock of Product the sum of all
• available Stock at each Warehouse
• e. Warehouse address4 is optional
• expressed in the multiplicity of associations (a)
• some tools will enable optional attributes (e)
• , and identifiers to be defined (c)
• others(b, d) will need to be defined using a
  formal language, such as Object Constraint
  Language(OCL)

48
Step 14 Pre- and Post-Conditions

• explain the behavior of the operation, from a
  users viewpoint, without needing to say how it
  is implemented
• example,
• listAddresses(inType, outAddressDetail )
• Description Returns all the addresses for the
  supplied type
• pre-condition inType must be H or W or T
• post-condition outAddressDetail contains all
  entries having type inType
• More complex behavior
• Design by contract
• Multiple pre/post pairs per operation
• Variables in pre- and post-conditions
• Referencing the interface type model
• Further Syntax
• Improved precision through OCL

49
More Complex Behavior

• Both pre- and post-conditions can be built from
  assertions connected by the boolean operators
  AND, OR and NOT
• It is also possible to include conditional logic
  in post-condition by IF/THEN/ELSE operators
• example,
• addAddress(inName, inType, inAddress, inPhone,
  outResult)
• Enables one new address and/or phone number to be
  recorded. The type parameter takes the value H,
  W or T to indicate whether it is a home, work or
  temporary address. If successful, outResult
  contains OK
• pre-condition inName must be non-null
• AND (inType must be H OR W OR T)
• AND (inAddress must be non-null OR inPhone must
  be non-null)
• post-condition A new Entry is created
• IF there is an existing Entry WITH (name inName
  AND type inType)
• THEN outResult Entry already exists
• ELSE a new Entry is created WITH (name inName,
  type inType, address inAddress, phone
  inPhone)
• AND outResult OK

narrative text description
sub-conditions
50
Design by Contract

• Software is designed based on a contract
  between the client of a software service and the
  provider of the software service, and the
  contract is expresses as a pre- and
  post-conditions
• n case of component-based development, this is a
  contract between the client of a component, and
  the component itself
• Client is obliged to conform to the pre-condition
• Provider is obliged to conform to the
  post-condition

51
Multiple Pre Post Pairs per Operation

• makes the post-conditions more understandable,
  reducing the number of conditional assertions
• pre condition-A OR condition-B
• post IF condition-A THEN assertion-A
• IF condition-B THEN assertion-B
• is equivalent to writing
• 1
• pre condition-A
• post assertion-A
• 2
• pre condition-B
• post assertion-B
• Each pair has been given a label. This label can
  be used within a pre-condition, as an abbreviation

52
Variable in pre- and post-condition

• It is actually possible to derive the type model
  from the pre- and post-conditions, but in
  practice it is suggested that a tentative
  interface type model is constructed first, and
  its then corrected as the pre and
  post-conditions are written.
• The variables referenced in pre- and
  post-conditions must be parameters or
  constructs(that is, types, associations or
  attributes) from the interface type model
• The pre-condition may refer to input parameters,
  and to the starting state of the interface type
  model
• The post-conditions may refer to the input and
  output parameters, and the starting and state of
  the interface type model

53
Referencing the Interface Type Model

• A dot operator is used to refer to an attribute
  of a type within the interface type model
• w is an instance of the type Warehouse
• w.code refer to the Warehouse code
• Same notation is used for navigating
  associations
• w.stockedItem yields a collection of StockItem

54
Further Syntax

• It is suggested that the operator are written in
  capitals
• SUM, MINIMUM, SIZE, INCLUDES, UNION,
  INTERSECTION, CREATED IN, DELETED FROM,
• productCreate (inNameString, inIdInteger,
  outProdProduct, outMessageString)
• Description To register a new Product, giving it
  the name and business identifier provided.
• successful_create
• pre-condition NO Product q EXISTS IN
  self.managedProduct WITH (q.Identifier inId)
• AND inName ltgt null
• post-condition Product p CREATED IN
  self.managedProduct WITH
• (p.instanceId some unique value
• p.Identifier inId
• p.name inName )
• outMessage Product created
• product_already_exists
• pre-condition Product q EXISTS IN
  self.managedProduct WITH q.Identifier inId
• AND inName ltgt null
• post-condition outMessage Product already
  exists

55
Improved Precision through OCL

• OCL(Object Constraint Language)
• Free text

formal
Adopt semi-formal language
informal
56
Discussion

• Happy?
• namkyu_cho_at_coolsoft.co.kr