Database Reference
In-Depth Information
sions that are outside the bounds of standard UML, which makes it diffi cult to apply one
of the existing UML-based modeling tools in practicing the method. The method provides
precise and detailed guidance on how to extend and customize the UML for the purpose of
component modeling and specifi cation. In essence, UML Components offer a subset of Ca-
talysis concepts together with a much simpler RUP-like process. Components are identifi ed
through identifying system interfaces that are related to use cases, and business interfaces
that are related to business entity types. Identifi ed components are further specifi ed through
the information types that represent the component state, as well as pre-conditions and post-
conditions on component operations that specify the component behavior.
The method lacks some of the key ideas of Catalysis, including the nesting of compo-
nents to arbitrary depths, the recursive application of development concepts, and the use of
frameworks to package larger-grained reusable structures. The UML components approach
does not take into account potential different levels of component granularity and importance
of using the separation of concerns in defi ning them. Despite some limitations, the UML
Components method contains important, practical advices for developers practicing CBD.
Business Component Factory
Herzum and Sims (2000) propose the Business Component Factory (BCF) approach
as a way to use components in enterprise system design. Both authors have been active in
the OMG's business object development efforts. The approach is split into three parts: i)
conceptual framework that covers CBD and component concepts, ii) component factory set-
up for putting the factory itself in place and iii) manufacturing component-based software
through modeling and design considerations. The authors suggest a classifi cation of compo-
nents that refl ects granularity: language class, distributed component, business component,
business component system, and fi nally, federation of system-level components. The method
provides little coverage of commercial implementation platforms such as J2EE, CORBA
or COM+/.NET. The focus of the method is on the business components that are defi ned
as important business concepts that are relatively autonomous in the problem space. Busi-
ness components can be of the following types: entity, process, utility, and auxiliary. These
components are more related to business object theory, which is logical since the authors'
background is in business objects. By separating entities and behavior, this approach does
not provide a uniform view on components. On the other hand the role and importance of
service-based interfaces are diminished to some extent.
The method further presents the set-up of the component factory from the viewpoint
of the development process, technical architecture, and application architectures, as well as
the project management architecture. Finally, the method proposes a number of modeling
and design steps and activities by focusing on the functional architecture. There is a lack of
precise modeling of the dependency and relationship between components, the importance
of which is stressed by the method, but not covered in detail. The approach does not use
the standard UML notation, which makes it diffi cult to relate it to the current UML-based
development practice. There is no information about practical experience in using the
method. No particular tool support has been proposed. The method is based on practical
experience of the authors; it is written by practitioners for practitioners. The central element
of the approach is the concept of business component. For the purpose of service-oriented
computing, the focus should be moved above that to coarser-grained business components
that are by the method called system-level components. Although authors briefl y defi ne a
