Unified Modeling: What, Why & How?

Background

The use of Unified Modeling Language (UML) has been one of the most important additions to software development over the last several years. It is supposed to be a big step towards sorting out silly conflicts over notation. It’s important, however, to understand that creating a UML diagram involves a cost and a UML model is not something that fundamentally matters to many customers. Customers are always interested in the working software that meets its requirements, not pictures or models. Hence the cost of creating a UML model for the system is usually born by the developing organization only. Yet it is important to avoid the silly mistakes in system analysis and to save resources and time by avoiding conflicts and inconsistencies. Since UML modeling is so important, one needs to know the focus of modeling and how to meet this focus. This article discusses how to use UML for system analysis and deployment before jumping into its development.

What's a Model

A model may be taken as a form of abstraction that omits undesired details and allows the designer to look into the important aspects and give them proper consideration. A model allows a designer to look at all the aspects of the system so that no important phase or point or detail is left without discussion and consideration. Overlooking important details may cause failure during later stages of development when the remedies are either impractical or too costly and time consuming. A model is used for understanding a system properly before its actual implementation so that the product may be developed in a cost effective and efficient manner. Also those systems developed with proper adequate understanding are much more maintainable and meet the user's requirements for a longer time.

Complex systems usually need to be simplified first, so that they may be properly understood and then developed in a maintainable way. For this the designer needs to consider the system from different view points with abstract details. These viewpoints give different "Views" of the system. These views then define a "Model" of the system.

Why Modeling?

While designing a system, we need to analyze and understand it from different angles or viewpoints and many different conceptual, logical, physical and other types of complexities need to be considered. For this we use different design strategies and models. Modeling creates a basis for implementing and testing the system. It also provides specifications for the system's use by the customer. It demonstrates the design idea in a presentable form. A model explains the system at some level of abstraction so that specific aspects of the system can be analyzed. The designer can use it to explain the architecture to software professionals and other abstract and relevant details to others. Modeling is a strong tool for planning the development of the system and checking the feasibility of ideas before committing to action. Modeling also provides a basis for testing and testability of the system before the system is actually implemented. Moreover, modeling can reduce the complexity of the system and hence save resources.

It is important to mention here that the design describes the designer's understanding of the system and explains the strategy to be adopted for development of the system at hand. Of course not all people think the same; some understand text more easily, while others may prefer graphic notations of the design. Here the model attempts to provide a common platform where the conflicts of the design may be resolved and a consistent design for implementation may be proposed. The use of a model is also important in catching silly mistakes while developing the system and in creating a means for evaluation during development. Its output is something more than a simple software system, but also produces a better understanding, documentation and maintenance tips.

OOMD and UML

Object Oriented Modeling and Designing (OOMD) is an innovation for Inception, Elaboration, Construction and Transition in the Software Development Life Cycle (SDLC). It is a way to analyze, design and develop a software system using concepts that have a direct correspondence to real world entities. We use graphic notations for object oriented construction of systems and visual modeling is one way to generate the notations. Visual modeling creates Object Oriented Models (OOM) of a system for its analysis, design and implementation in an object oriented language. We create OOMs for complex systems to better understand them and to create a better, more efficient design. We use different graphical notations with lots of documentation for a proper and unambiguous understanding of the system. To model the systems in this manner, we can use a widely accepted notation known as Unified Modeling Language (UML). UML defines a set of graphical notations for different entities and terms used in the Object Oriented Modeling of any system.

How to start: Static Analysis

The system development life cycle starts with a problem statement from which a use-case model is created. In this statement, it is important to capture the understanding and use of the system. Here the system is represented at the highest level of abstraction, i.e. generally as a single unit that can be used for some purpose. It includes all possible conversations (termed as use cases) between a user (termed as actor) and an operator in the system during any task. Sequence of occurrence of the dialogues is not important in a use case model and it is not necessary to show how the system is performing its task. It only shows how a system interacts with its environment/user.

The Next Step

Once the system and its interaction with its environment are understood, the analysis part of system development life cycle (SDLC) is almost complete and the next step is to design the system. This design will later be implemented in high level code, which is then converted into executable modules and installed in the environment of the system, but the design creates a base framework to move forward towards implementation.

In unified modeling, class diagrams are created for this step of SDLC. The appropriate classes can be found in the list of nouns used in the problem statement. These classes then interact with each other in terms of message passing. The classes become templates for objects in the system and hence we need to clearly show the attributes as well as methods. The class diagram creates a base for implementing the system in any object oriented language, so that the lack of proper description of types or interactions between classes in the class-diagram not only can weaken the quality of the system but can also introduce inconsistencies into the system. It is therefore important to clearly describe all required class templates and interactions between the classes. For more clarity, this analysis should be done at different levels of abstraction from top to bottom.

Dynamic Analysis

Static analysis is followed by an analysis of the dynamic behavior of the system. Here the unified-model uses sequence diagrams and state diagrams. From a software implementation point of view, state diagrams may not be of direct use but they may be useful in understanding the system dynamics in terms of some finite number of system states. This finite state analysis helps the developer to avoid many inconsistencies and exceptions at run-time. The state diagram should clearly show the transitions between states that occur with some event or when a message is passed between two classes. The state diagram is highly important in enhancing the performance of concurrent processing or multi-threading systems.

System Dynamics

System dynamic analysis includes another important analysis called "sequence analysis." Sequence analysis considers the sequence of occurrence of events and operations and provides direct information for implementing a function or method. While creating a sequence diagram for a task or function, it should be kept in mind that sequence analysis is a sort of boundary between the design and implementation phases of SDLC. This means that a sequence diagram should be able to describe the direct mapping of the design to its coding in a programming language. The sequence diagram is essentially a graphical representation of the algorithm to implement a task in the system.

Sequence analysis is important for each and every task. At the lowest level of abstraction, all the functions and methods included in a class are analyzed for the occurrence of sequences of operations. This sequence can then be implemented in the chosen high level (object oriented) programming language for the required function. The best sequence diagrams are expected to describe all the required programming instructions in the form of message-passing events.

Unified Modeling for System Deployment

After static and dynamic analysis and the design of the system, the software is implemented in a programming language and installed in its working-environment including other interacting software, hardware and user interfaces. To analyze the design before system implementation, deployment views in UML are used to show other interfaces, both software and hardware, communication media and communication buses present in the environment. In the deployment diagram, the information about the type of communication buses, server configuration, database architecture, type of interfaces with other hardware and software, etc. should be clearly mentioned.

Conclusions

There is little doubt that the design phase is one of the most crucial and resource consuming phases in SDLC and that it also has very little of direct interest to the consumer. The developing organization itself, in many cases, is expected to bear the net cost of designing and modeling. In such a scenario, Unified Modeling has rapidly become the standard notation for modeling software-intensive systems. Companies today are interested in the entire project development life cycle and how it ties into Unified Modeling and in most cases, the various methodologies can be easily adapted. Unified Modeling provides a complete modeling at almost every stage of SDLC right from the beginning of the requirements analysis to deployment of the system, including the implementation model and dynamic behavior model.

For those of us who have built software and designed databases for many years, unified modeling can help reduce the risk in the development process. Although the unified modeling is not a specific SDLC process, it offers a concise and workable notation that can be applied to any domain.