CASoft Blog     CASoft Blog

         Communication Aspects in Software Engineering

12 September 2009

The under-estimated benefits of components

Filed under: UML — Tags: , , , — admin @ 18:02

Components Based Architecture has been formalised and publicised by UML-RUP more than 10 years ago, and the benefits of this approach are still unknown or under-estimated by most.

It escapes me how, in the 21st century, enterprises can ignore the return on investment (ROI) that can be achieved with components.

The most commonly missing piece in the software engineering puzzle today is the architecture document. I keep seeing projects after projects documenting detailed designs after gathering the requirements and no architecture.

When no components based architecture exists, Managers are reduced to finding and selecting solutions at project level.
With well documented components, encapsulating meaningful functionality, it is for example possible to:

  • Find Commercial-Of-The-Shelf (COSTS) solutions for one or several components.
  • Outsource the development of low added-value components.
  • Reuse components from other applications within the company.

Components are however a science and there is more to it than what meets the eye…
See previous article RUP – Component Based Architecture

11 May 2009

RUP – Software Component Architecture

Filed under: RUP,UML — Tags: , , , — admin @ 09:11

What is Architecture?

  • In computer science, Architecture is the nature and structure of a system that determines the way it operates.

What Architecture is not:

  • Architecture is not a Framework: While an architecture can take into account the use of a framework, the definition of a framework is not sufficient! A framework is just one component.

The Technical Architecture (or Model of Architecture) is the nature of the system. For instance, it could be:

  • Monolitic
  • Client Server
  • Distributed
  • N-tier

Paradigms can be integrated, such as:

  • Model-View-Controller
  • Software Components
  • Design patterns

A framework can be defined, as part of the technical architecture.

The business architecture defines the structure of the system.
It should outline the different parts of the system, their role and their relationships, as for instance:

What Does Component Architecture Mean for RUP?

  • Components are cohesive groups of code, in source or executable form, with well-defined interfaces and behaviours that provide strong encapsulation of their contents, and are therefore replaceable.
  • Architectures based around components tend to reduce the effective size and complexity of the solution, and so are more robust and resilient.
  • In the examples below, there is the same number of objects, but a different level of complexity:

Definition for Software Component

  • A Software Component is an independent portion of code that is accessed through a defined interface.
  • Software Components may be just imaginary, and can always be defined whatever the technology used!
  • Software Components may also be physical entities, such as a library (e.g. DLL) or a distributed component (e.g. EJB, CORBA, DCOM, Web Services, etc.)… but not necessarily… and it is not because EJB are used that it is a well-thought Software Component Architecture.
  • Physical Software Components may be reused, purchased and/or replaced.

Business components are those that implement the functionality specific to a business.
A “Computation Engine”, which provides specific computation services, is an example of a business component.
Business components are more difficult to reuse than technical components, due to their specific nature.

Technical components are those that implement generic functionality.
An example of a technical component is “Document Printing”.
Technical components can be designed in order to be reused. They can be part of a technical framework.

Why using Software Components?

  • They usually manage to reduce the complexity of a software, by identifying well defined interfaces and independent portions of code.
  • While it is rather inefficient to give Use Cases to develop to Programmers directly, it is much more effective to give components to implement. ==> Would you envisage to outsource the development of a use case? It is easy to outsource the development of a component, or to buy an existing one.
  • This approach eases and improves workload estimations, planning & task assignment.
  • To reuse components is an efficient way because they are already developed and tested.

Components can be developed in order to be reusable, especially the components that provide common solutions to a wide range of common problems.
These reusable components, which may be larger than just collections of utilities or class libraries, form the basis of reuse within an organization, increasing overall software productivity and quality.
Before promoting furious reusability however, ensure that great experience and knowledge has been acquired in the domain of software components.

Because they are well defined, Components can be refactored with less pain than in a not-so-well structured / organised Architecture.
The interface of the component may be mostly unchanged, while the implementation is entirely reviewed.
Even if the interface is changed, finding the impacted code will be easier than finding what is using the multiple classes and methods that compose the component.

In the beginning of Software Development, documentation and system integration were usually poorly undertook, the Architect was often asked to contribute to the development effort, and the Customer would get to perform most of the testing.

RUP recommends to implement “Use Case Packages” as components for requirements, in order to gather requirements by type of functionality.
Indeed this approach will ease the following analysis and design of the application with software components.

Identifying components may be performed this way:

  • Identify different modules, packages, subsystems and layers, e.g. Billing and Subscription modules.
  • Try to find common features, e.g. printing out.
  • Split modules, define interfaces and relationships with other modules.
  • Iterate and go deeper to find as many components as possible. Use top-down approach, from Graphical Interface towards Data, and bottom-up approach at the same time.
  • Then apply patterns such as Model-View-Controller.

The Components specification will provide a brief description of the components and their relationships.
The result is usually described with Composite Structure or Component Diagrams and accompanying text, providing a high-level description for each component.

The Components Analysis will provide a brief definition of each component, and a detailed definition of its interfaces and relationships.
At this stage, Components are black boxes.
The result is usually obtained and described with Sequence Diagrams and/or Collaboration Diagrams. Class Diagrams can be used to describe the interfaces.

The Components Design will provide the detailed description of what is inside each component / inside the box.
The result is usually obtained and described with Sequence Diagrams, Collaboration Diagrams, Class Diagrams, State Diagrams, etc.

The implementation of the components can now easily be performed by a Developer or a Team.
The team will be responsible for maintaining the design of the component and for unit testing the component.
The team might be the supplier and/or the customer for another component/team.

Components can be individually tested and gradually integrated to form the whole system.When performing unit tests of a component, moke components (giving fake answers) can be used to form the test-bench of the component to test.

Note also that Service Oriented Architectures (SOA) are necessarily based on Software Components Architectures. Components are then implemented as services (Web-services, CORBA, RMI, etc.), which provide the benefit of being loosely coupled.

25 February 2009

Introduction to RUP

Filed under: RUP — Tags: , , — admin @ 20:09

Are you a Pointy Hair Manager?

Think again… Look in a mirror.
You run the risk of finding a Dilbert cartoon taped on your door some day if you think that:
–Software development is primarily about programming,
–Managing a software project is no different to managing any other project,
–The best approach is to establish a detailed plan at the beginning and make sure everyone abides by it on a daily basis,
–A safe way to proceed with the product is to freeze all requirements early, in order to minimize any risk of schedule slippage and late surprises,

The Rational Unified Process (RUP) is a Software Engineering Process.
–It provides a guide to help determine who does what, when and how.
–It can be mixed with other methods (e.g. quality insurance, CMMI, Agile…).

Why to apply RUP?
–Computer systems complexity.
–Reproducibility and Predictability.
–RUP gathers best practices that have proven themselves.

RUP, 3 Foundations:

–Use case driven,
–Architecture centred,
–Iterative and incremental.

RUP, Best Practices:

1.Iterative approach
2.Requirements management
3.Software component based architecture
4.Graphical modelisation of concepts
5.Permanent software quality checking
6.Change control

Maturity Level:

The Capacity Maturity Model Integration (CMMI) is process oriented and defines 5 levels of maturity:
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimising

RUP uses the process approach and allows an organisation to reach CMMI levels 2 or 3.

RUP Software development life cycle is organised into phases:

Iterative Approach:

Time Organisation:

Requirements Management:

–Discovering user requirements,
–Writing business use-cases with scenarios.
–Reorganising business use-cases into use-cases with attributes.
–Tracking requirements all along the development process.

Graphical Modelisation and Component Based Architecture are important subjects and will be the object of an article on their own.

Permanent Quality Checking:

ISO definition for quality:
–Quality is the property of what is conform to the requirements

Quality checking:
–Metrics assessment
–Defect tracking
–Code review
–Phase and iteration review
–Project tracking

Change Control:

–Change Request Management
–Configuration Management

Worker-Activity-Artifact diagrams are provided as guidance for the different processes of Software Engineering.


It is recommended to organise projects in smaller groups in order to facilitate communication.

Risk Management:
The adoption of an iterative approach allows the reduction of the risks earlier in the project life cycle.

These are recommendations and guidances, which are to be tailored to your needs, to the size of the project and to the size of the company.

The Unified Process allows to improve the quality and control over Software Development Life Cycle (SDLC), in order to:
–reinforce capacity to reach defined goals,
–decrease the cost of the whole software development, especially maintenance.

RUP has also proved that it can be light and agile.
Useful Resources:
Mapping between RUP and PMBoK article:

Powered by WordPress and