October
2003 Issue: 29
October
2003 Issue: 29
Journal of Conceptual Modeling
www.inconcept.com/jcm
Introduction
Services are the
basic concept in a service-based architecture. Component-Based Development (CBD)
is a service-based architecture. The services are usually categorized into three
groups: user, business and data services. We can group different services into
packages and provide them orthogonally. Being able to do this has got lots of
advantages for reuse and maintainability purposes. User services (providing GUI
etc) and data services (providing access to database etc) are implemented by the
technology classes. These classes may change as we find ways of improving these
services. So the modification to these service classes will not affect the
business classes, which are generic in nature and concern only with the business
rules.
In this article, a try has been made to see CBD from a developer’s perspective. We shall see that support does exist in terms of modeling the CBD process, but the level of support differs significantly at different stages of the process. We will see how UML supports a service-based architecture and what sorts of model it provides for the different people in the development team. We try to explore the different models provided by UML to analyze, design and implement the Component-Based systems and see what sort of support do they provide for the different levels in development process.
Graphical representation of Components and Interfaces
UML provides a range of
models to support Component-Based development of the systems. UML has also got
the graphical representation of the Component. Graphically a Component is
rendered as a rectangle with tabs, usually including its name. A Component
typically represents the physical packaging of otherwise logical elements, such
as classes, interfaces and collaborations.
Components are seen as black boxes. One concerns only with the services it provides. Components offer their services via well-defined interfaces. An interface describes the externally visible behavior of a Component. These services are then provided (implemented) by the Components that realize the interface. A Component may realize any number of interfaces. The services of a Component can only be accessed via the interfaces it realizes. An interface also has a graphical representation. It is rendered as a circle with name on it.
A Component may depend on any number of Components to provide its service or to complete its service implementation. A Component depends on another Component means that it depends on the interface of the Component that realizes it. A line from Component to the interface represents the realization of interface. Component dependency is represented with a dashed line with an arrowhead pointing towards the interface.
Models
useful for CBD
UML does provide support CBD by providing various kinds of models that can be
very useful for the development of such system. Some other notations also exist
which are specific to the Component-Based system like Component-Event Diagrams
(CED). The kinds of model that can be used for the CBD are as follows:
· Component diagram
· Package diagram
· High level class diagram
· Use-case diagram
· Interaction diagrams
· State-transition diagram
· Deployment diagrams
Component diagram shows the organization and dependencies among a set of Components. This is a static view of the system. They are related to class diagrams in that a Component typically maps to one or more classes, interfaces, or collaborations.
In software, many operating systems and programming languages directly support the concept of a Component. Object libraries, executables, COM+ Components, and enterprise Java Beans are all examples of Components that may be represented directly in UML using Component diagrams. [Booch, Rumbaugh, Jacobson 98]
Apart from modeling Components, Component diagrams are also capable to model other things like tables, files, and documents.
A Component is the physical implementation of a set of logical elements such as classes, interfaces, collaborations and other things. The relationship between a Component and the classes it implements may be shown explicitly by using a dependency relationship. But most of the time we just describe this in the specification of the Component and only represent the relationships between a Component and the interfaces realized by it.
An example of Component diagram
You may show the relationship between a Component and its interfaces in one of two ways. The first (and the most common) style renders the interface in its elided, iconic form. The second style renders the interface in its expanded form, perhaps revealing its operations. [Booch, Rumbaugh, Jacobson 1998]
A package, in UML, is a general-purpose mechanism for organizing elements into a group. Structural things, behavioral things, and even other grouping things may be placed in a package. Unlike Components (which exist at run time), a package is purely conceptual (means it exists only at development time) [The Unified Modeling Language, Booch, Rumbaugh, Jacobson, 1998].
It is hard, sometimes to represent Component from a design perspective. To overcome this, we can introduce the notion of subsystem to represent it for design. Subsystem means a number of classes that interact together to provide a set of services [“A Practical Framework for Applying UML”, Paul Allen].
We may use this mechanism to package a set of different classes interacting together to provide different services. A Component can then be represented in a package diagram in which each package may be deemed as a Component.
We can have packages providing services of different categories, user, business or data services.
A deployment diagram shows the configuration of run-time processing nodes and the Components that live on them. Deployment diagrams address static deployment view of an architecture. They are related to Component diagrams in that a node typically encloses one or more Components [Booch, 98].
Use-case diagrams (although not part of UML) may be very helpful for the behavioral modeling of Component-Based System at the outset. Different UML diagrams, mentioned above, are used at the different stages of CBD. Some are useful at the very beginning and some at the later stages of the process. The Use-case diagrams will be very helpful for the analysts to understand how system will work at initial stages. Analysts are mainly concerned with the information in the problem domain (the context); they don’t go very deep in software (implementation). High-level Use-cases stay free from implementation. Since Use-cases view the system behavior at the boundary, they might not be as helpful as an implementation class diagram or interaction diagram for the implementers.
An example of Use-case diagram from library system
Interaction diagrams represent the dynamic view of the system. We can go close and close to see the inner details of the system by utilizing them. They provide visibility to see the interaction between different Components classes and objects. Sequences diagram, one of the interaction diagrams, is very useful to describe the messages passed among different Components, classes or objects.
Collaboration diagrams are also very helpful to find the interaction between the object of different classes or Components.
There may not be a formal approach for modeling Component-Based systems but support for CBD does exist in the form of UML. UML is able to provide different models for the Component software that can help designers, analysts, and implementers to develop such system.
By looking at glance on UML models discussed above, it seems that relatively lesser support is available for analysts than designers or implementers. Components are “black boxes” and provide services via interfaces. To understand the functionality of a system, one needs to look the inner structure of the system. This really is a problem for the analysts as they are not concerned with the inner details. They rather analyze the context of the problem. Also CBD has got more tendencies towards implementation of system because a major activity in CBD is the rapid integration of existing Component for the fast delivery. The more emphasis is on synthesis. A process that tends towards implementation may make analyst work hard in terms of system analysis.
On the other hand, we can focus on developing the business systems by using Components for the user and data services. This can help ease designers and implementers focus on designing and implementing business’ specific needs. Packages diagrams also seem to be more helpful during the design activity of the systems. Diagrams such as Component diagram, interaction diagrams, and deployment diagram are more like implementation-oriented and provide significant help in visualizing and implementing the system.
There are three major consortiums seem to be providing support for the CBD. OMG, SUN and Microsoft are all working on Components from different directions. JavaBeans, CORBA and COM+ are the being the three successful examples of the Component Technologies.
References
1. The
Unified Modeling Language, User Guide, by Grady Booch, James Rumbaugh, Ivar
Jacobson, Addison-Wesley 1998.
2. Component-Based software engineering, by Thomas Jell, Cambridge University
Press; (June 1998).
3. Software
Engineering, A Practitioner’s Approach, Fourth Edition, Roger. S. Pressman,
McGraw-Hill, 1997.
4. A
paper on “Modeling Component Systems with the Unified Modeling Language”,
Philippe Kruchten 1999, Rational Software Corp.
5. Adoption
of Software Engineering Process Innovations; Fichman & Kemerer, Sloan Management
Review/ Winter 1993
6. A
paper on “A Practical Framework for Applying UML”, Paul Allen, SELECT software
tools.
7. Modeling
Component Systems with the Unified Modeling Language, Philippe Kruchten,
Rational Software tools.http://www.sei.cmu.edu/cbs/icse98/papers/p1.html
8. Brown,
A. (1998), ‘Unified Modeling Language (UML)’, Sterling Software,
http://www.cool.sterling.com/cbdedge1/techwatch.htm
9.
Home page
of Component Source, A Component Vendor Company
http://www.Componentsource.com/home/AboutComponents.asp
Amjad
Bashir,
Chairman
Department of Computer Sciences & I.T.
Contact Information:
Amjad
Bashir
Chairman
Dept. of Comp. Sc. & IT, Old Campus, University of AJK,
Muzaffarabad 13100. Pakistan.
nashanaas@hotmail.com
© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement. ISSN: 1533-3825