Unified Modeling: What, Why & How?

Executive Summary

The use of Unified Modeling Language (UML) has been taken as one of the most important parts of software developments in the last couple of years. It is supposed to be a big step towards sorting out silly conflicts over notation. It’s important to know that creating a UML diagram involves a cost, and a UML model is not something that fundamentally matters to a customer. Customers are always interested in the working software that meets its requirements, not pictures & models. Hence the cost of creating a UML model for the system is always bearable by the developing organization only. Yet it is important to avoid the silly mistakes in system analysis and to save resources & time by avoiding conflicts & inconsistencies. Being UML modeling so important, one needs to know the focus of modeling & how to meet this focus. This collection of words includes about how to move with UML for system analysis & 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 more important aspects and elaborate them with proper consideration. A model allows a designer to look into all the aspects of the systems so that no important phase or point or detail is left without discussion and consideration that may cause failure of development in later stages where the remedy actions are either impractical or they are too costly & 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 the systems developed with proper understanding are much more maintainable and feed to user requirements for long time.

To build complex systems, they need to be simplified first so that they may be properly understood & then developed in a maintainable way. For this the designer needs to watch the system from different focus points with abstract details. These focus-points give different “Views” of the system. These views of the system give a “Model” of the system.

Why Modeling?

While designing a system, we need to analyze and understand it from different angles & view points. So many different conceptual, logical, physical and other types of complexities need to be solved. For this we use different design strategies and models. Modeling creates a base for implementation of the system and its testing. It gives specifications for its use by customer. It explains the design idea in a presentable form. A Model explains the system at different levels of abstraction. At a time, it provides a selective aspect study of the system. The designer can use it to explain the architecture to the professionals and abstract and relevant details to others. Modeling it a strong tool to plan the steps in development of the system and check the feasibility of ideas before final actions on it. Modeling also provides a base for testing and testability of the system before the system is actually implemented. Moreover, modeling reduces the complexity of the system and hence saves resources.

It is important to mention here that the design is only a concept that describes the system understanding of the designer. It tells the thinking of an experience-holder about the strategy to be adopted for development of the system in hand. Now all human does not think in the same way. Some may have better understanding in textual form while others may prefer graphic notations of the design. Here the model efforts to bring them on an almost common platform where the conflicts of the design may be resolved and some consistent design for implementation may be proposed. Model is also important to remove the silly mistakes while developing the system and also creates a scale for evaluation while development. Its output is something more than a simple software system with its better understanding, documentation and maintenance tips.

OOMD & UML

Object-Oriented Modeling & Designing (OOMD) is an innovation for Inception, Elaboration, Construction and Transition in Software Development Life Cycle (SDLC). This is a way for analyzing, designing and developing a software system using concepts having direct correspondence with the real world entities. We use graphic notations for Object-Oriented construction of systems. Visual Modeling is one way for generating these notations. Visual modeling creates Object-Oriented-Models (OOM) for a system under construction for its analysis, designing & implementation in an object-oriented language. We create OOMs for complex systems under construction for their better understanding and a better & efficient designing. We use different graphical notations with lots of documentations for a proper & unambiguous understanding of the system. For such modeling of the systems, we can use a globally accepted media known as Unified Modeling Language (UML). UML gives a set of graphical notations prescribed for different entities & terms used in Object Oriented Modeling of any system.

How to start: Static Analysis

The system development life cycle starts with a problem statement using which a use-case model is created which is important to state the understandability & usability 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 to be mentioned in a use case model. Also it is not required 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 & its interaction with its environment are understood, the analysis part of system development life cycle (SDLC) is almost complete. The next step is for designing the system. This design is later implemented in terms of some high level codes, which are then to be converted into executable modules and installed in the environment of the system. Hence designing 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 from problem statements from the list of nouns used in the problem statement. These classes interact with each other in terms of message passing. The classes create templates for objects in the system and hence we need to show the attributes as well as methods involved in the template clearly. Class diagram creates a base for implementation of the system in any Object-Oriented language. Lacking a proper description of types or interactions of classes in the class-diagram not only can weaken the base of quality of the system but can also introduce many inconsistencies in the system. So we need to clearly describe all required templates and interactions between them. For more clarity this analysis is done on different levels of abstractions from top to bottom.

Dynamic Analysis

Static analysis is followed by analysis of dynamic behavior of the system. Here the unified-model members include sequence diagrams & state diagrams. For software implementation point of view, the state diagram may not be of direct use but they serve for understanding the system dynamicity in terms of some finite number of states. This finite state analysis helps the developer to avoid many inconsistencies and exceptions at run-time. The state diagram clearly state the transitions of states on occurrence of some event or message passing between two classes. State diagram is highly important in concurrent processing or multithreading system designing & enhancing their performance.

Next in System Dynamics

System dynamic analysis includes another important analysis what we call ‘sequence analysis’. Sequence analysis talks about sequence of occurrence of events & operations. Sequence analysis gives direct information for implementation of a function or method. While creating a sequence diagram for a task or some function, it should be kept in mind that sequence analysis might be taken as the boundary of designing & implementation phases of SDLC from where we might be able to see both sides of the boundary. This means that a sequence diagram should be able to describe the direct mapping for the design to its coding in the programming language. Hence the sequence diagram can be understood like a graphical representation of the algorithm to implement a task in the system. The 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 occurrence of sequences of operations in it. This sequence can then be taken as it is and 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 & dynamic analysis and designing of the system, the software is implemented for the system in programming language. After that, the system needs to be installed in its working-environment including other interacting software, hardware and user interfaces. To analyze it before system implementation, deployment views in UML are used to show other interfaces, software & hardware, communication media and communication buses present in the environment. In deployment diagram, the information about the type of communication buses, server configuration, database architectures, type of interfaces with other used hardware and software etc. should be clearly mentioned.

Closure

No doubt that designing is one of the most crucial and resource consuming phase in SDLC and that’s too the one which has nothing of direct interest of the consumer. The developing organization itself is expected to bear the net cost of designing & 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 the Unified Modeling. In most cases, the various methodologies will easily adapt to it. Unified Modeling provides a complete modeling at almost every stage of SDLC right from the beginning of requirement analysis till deployment of the system covering implementation model and dynamic behavior model also. For those of us who have built software and designed databases for many years, unified modeling will also remove additional risk from the development process. Although the unified modeling is not a SDLC process, it offers a concise and workable notation that can be applied to any domain.