THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

UML IN A PRODUCTýS LIFE CYCLE

by Venu Kosuri

Start ý Basic Views ý The Whole Picture ý Use Case View ý Use Case Diagram ý Structural View ý Domain Modeling ý Class Diagram ý Behavioral View ý Sequence Diagram ý Collaboration Diagram ý FSM ý Scalability Limitations ý Lack of Support ý State Charts ý Activity Diagram ý Implementation View ý Environmental View ý Sources and PDF

THE WHOLE PICTURE

Use case diagrams are often used for gathering requirements of the product. After this aspect of the system is defined, evolution begins. Of all the requirements, some are implemented in hardware and some are implemented in software. This is basically decomposing the system into hardware and software partitions. This is an entry point for the development of software as well as hardware. After the software system is defined, then decomposition of the software system can take place, which is nothing but domain classification.

It is important to understand the dynamic behavior of the system after structuring the system. In order to capture this, sequence diagrams are used to anticipate all the scenarios that the system is expected to go through. For complex systems, the state approach is also used to get the clear distinctions of the systemýs states and related scenarios. Understanding thoroughly the dynamic behavior of all domains is an entry point to define the requirements of each domain and the general mechanism of communication among the domains.

Domainýs requirement is to realize the domain. So, each domain is broken into a set of components, or modules. Primarily, all components act together to perform a desired requirement of the domain. Component diagrams capture this information. For real-time embedded systems, the port-based approach is most used. Each port defines a specific protocol that is responsible for communication among specified components. This component division is a starting point to understanding the component.

If the component is being developed with OO techniques, class diagrams, sequence diagrams, state diagrams, and collaboration diagrams will capture the essence of the component for implementation. Of course, whether or not all of these diagrams will be used is based on the complexity of the component. But often, just a class diagram is sufficient.

Suppose the component does not have any threads of its own (i.e., passive component). Package diagrams work best to decompose the component into subcomponents, which are easily implemented. Here, subcomponents are small entities that implement a specific functionality of the component.

Deployment diagrams and activity diagrams are rarely used. Activity diagrams are similar to flowcharts except for the fact that parallelism can be shown in activity diagram. Generally, if a method of class or a function is big, itýs better to use activity diagrams. However, most developers use flowcharts. If the system is physically big, deployment diagrams are used to show physical layout.

Now, let us apply these diagrams and their relevance in a product or system evolution.

PREVIOUS • NEXT