UML

UML Reloaded

UML, an acronym to Unified Modelling Language, is defined as the graphical notations of the real system which allows both design and viability of a system. The requirements elicited from business owners are sometime too complex to explain to the stakeholders and thus to summarize those requirements and abstract the essential details UML is widely used. It helps in visualizing the problem and in turn the solutions with better approach and reduction of cost and rework. In short UML is a mean to visualize, specify, construct and document software systems.

Graphical modeling languages have been around in the software industry for a long time. Some articles show that this technique is being used for more than 15 years now. The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open consortium of companies. The OMG was formed to build standards that supported interoperability, specifically the interoperability of object-oriented systems. The OMG is perhaps best known for the CORBA (Common Object Request Broker Architecture) standards. UML is so wide and vast that nobody, not even the creators of the UML, understands or uses all of it. We all use a small subset of the UML.

The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open consortium of companies. The OMG was formed to build standards that supported interoperability, specifically the interoperability of object-oriented systems. The OMG is perhaps best known for the CORBA (Common Object Request Broker Architecture) standards.

UML is used in formal language with simple and straight forward annotations and it can be used as a sketch or blueprint to highlight the key points. It captures the static and dynamic aspects of the system using different diagrams.

UML Diagrams

Use Case Diagrams: Use case diagrams describes the functionality described by the system. It consists of different attributes viz. Actors, use cases and relationships.

Actors are classified as the living or non-living beings who interact with the system and are not the part of the system. These actors are represented by nouns in the use case diagrams. Actors are classified as primary and secondary. Primary actors initiate the action while the system depends on secondary actors for information. An actor is like a black-box: you can’t change it and you are not interested how it works but it must interact with your system says Zubin K in one of his workshops.

Use cases are the distinctive functions or activities to be performed by the actors. It completely describes the functional requirements so that the full requirements can be understood easily. The use cases stay from the non-functional requirements and describe the functionality as the action items e.g. use ATM, withdraw cash, create an account etc. A good use case should provide measurable result to the user or external system and should be able to design the test cases.

The actors and use cases are connected by communication lines which show the actor performing any action. Let me also clear here the difference between activity and actions. The word activity is often mistakenly used instead of action to describe a step but they are not the same. An activity is the process being modelled but an action is a step in the overall activity. E.g. washing a car is an activity but lather, rinse and dry are the actions performed while washing the car.

Relationships defined between two “use cases” are basically the dependency between two use cases. Relationships are further classified as below:

  • Association: An association is a relation between two use cases that describes the reason of relationships and the rules to govern those relationships. E.g. A professor wrote a book, here wrote is an association between author and book.
  • Generalization: It is also known as parent-child relationship. The child use case in the generalization relationship has the fundamental business meaning but it’s the extension of the parent child. In this relationship, if any of the parent or child is removed from the process, the business flow has no impact. E.g. maintaining records of hardware inventory in computerized file or in a paper file. Here paper file is parent and computerized file is child and either of them can be replaced or removed without any impact on the business flow.
  • Include: Here the functionality of one use case is included in another use case and it supports the reuse of the functionality. e.g. making an appointment in any hospital will include the validation of the patient’s records or opening a bank account includes the identity verification.
  • Extend: In this relationship, the behaviour of one use case is extended. These extend relationships are optional and dependant either on runtime or system implementation decision. E.g. checking invalid password while login. The extend relationships become more complex with the complexity of the requirements.

Example of Use Case Diagram

A bank provides ATM facility to its account holders but in maintaining the same ATM different bank personnel are required.

Activity Diagram

Activity Diagram describes the work-flow behaviour of the system. It is system or process oriented diagram and is not bounded with the actors. It explains the different activities happening in the system and the actions taken against those activities. Activity diagram contains different key elements which explain the flow of the diagram. The following diagram explains the activity flow diagram in which the sphere shows the details of the activities, Fork is the bar which documents the parallel activities. A diamond symbol is the decision node and as per the decision the flow changes. Merge allows the different flows to combine together and lead to the final activity.

Sequence Diagram

Sequence diagram describes the sequential set of interactions performed by the group of the objects. It explains the responsibilities of the different objects involved in the different activities to complete the process. E.g. a customer in a restaurant orders food and wine. The waiter takes his order and passes the food order to chef and serves wine. The description is shown in the below diagram:

The other UML diagrams used by different business analyst and developers are Class diagrams, Object diagram, Package diagram, Communication diagram and many more.

Happy Learning!!!!

One thought on “UML Reloaded”

Leave a Reply