CS302: Software Engineering (2021.B.01)

Introduction

In the field of engineering, the norm is to model first before implementation. Modeling can be mathematically or graphically, This unit presents a Unified Modeling Language as a language to model object-oriented artifacts. 

Engineering Norm 

For many years, the term object oriented (OO) was used to denote a software development approach that used one of a number of object-oriented programming languages (e.g., Java, C++). Today, the OO paradigm encompasses a complete view of software engineering. 

The norm for engineering analysis and design systems emphasizes modelling of the system first before implementation. Modelling is a proven and well-accepted engineering technique. Modelling can be done mathematically or by any other common notation understood by many engineers of the same field worldwide.

Software Engineering had lacked such a notation. Between 1989 and 1994, more than 50 software modelling languages were in common use – each of them carrying their own notations. Each language contained syntax peculiar to itself, whilst at the same time, each language had elements which bore striking similarities to the other languages, and bad enough neither of these languages were complete. 

UML Background 

In the mid 1990's, three methods emerged as the strongest. Ariadne Training (2001) state that these three methods had begun to converge, with each containing elements of the other two. Each method had its own particular strengths:

• Booch was excellent for design and implementation. Grady Booch had been a major player in the development of Object Oriented techniques for the language.
• Object Modelling Technique (OMT) was best for analysis and data-intensive information systems.
• Object Oriented Software Engineering (OOSE) featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behavior of an entire system (an area where OO has traditionally been weak).

So, the Unified Modelling Language (UML) is largely the product of three well known software engineers, - Grady Booch, Ivar Jacobson and James Rumbaugh. In 1994, James Rumbaugh, the creator of OMT, joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method. By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (particularly the concept of “Use Cases”) were fed into the new Unified Method – now called the Unified Modeling Language (Ariadne Training, 2001). 

The Unified Modelling Language or the UML as a graphical modelling language aimed at providing syntax for describing the major elements of software systems (called artifacts in the UML). The UML represents a collection of best engineering practices that have proven successful in the modelling of large and complex systems. In this course we need to explore the main aspects of the UML, and describe how the UML can be applied to the software development process.

What is UML?

Booch et al, (2005) defines the Unified Modelling Language (UML) to be a language for: Specifying, Visualizing, Constructing and Documenting the artifacts of a software-intensive system. It is a standard language for writing software blueprints. It is a graphical language for capturing the artifacts of software development. UML is the de-facto standard for Object Oriented modelling. 

 a) The UML as a Language for Visualizing: 

For many programmers, the distance between thinking of an implementation and then pounding it out in code is close to zero. You think it, you code it. In fact, some things are best cast directly in code. Text is a wonderfully minimal and direct way to write expressions and algorithms

b) The UML as a Language for Specifying: 

Specifying means of building models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made in developing and deploying a software-intensive system.

c) The UML as a Language for Constructing: 

The UML is not a visual programming language, but its models can be directly connected to a variety of programming languages. This means that it is possible to map from a model in the UML to a programming language such as Java, C++, Visual Basic or PHP, or even to tables in a relational database or the persistent store of an object-oriented database.

Things that are best expressed graphically are done so graphically in the UML, whereas things that are best expressed textually are done so in the programming language. This mapping permits forward engineering: The generation of code from a UML model into a programming language.

d) The UML as a Language for Documenting: 

A healthy software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include (but are not limited to): Requirements, Architecture, Design, Source code, Project plans, Tests, Prototypes, Releases.

Depending on the development culture, some of these artifacts are treated more or less formally than others. Such artifacts are not only the deliverables of a project, they are also critical in controlling, measuring, and communicating about a system during its development and after its deployment. 

The UML addresses the documentation of a system's architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modelling the activities of project planning and release management.

The UML can also be a Language for Communication. That is communication with customers has proven to be equally problematic. Graphical modelling can make people (technical and nontechnical) understand the artifacts of the software system expected. In software development, some of the things that require communication include requirements, design, implementation, and deployment. UML is a language designed to communicate these things. 

As with any language, the UML has its own notation and syntax. It does not tell you how to develop software. It can be applied in any software development processes; waterfall model, spiral model, iterative, incremental frameworks. Its notation comprises a set of specialized shapes for constructing different kinds of software diagrams. Each shape has a particular meaning. UML is a generic, broad language enabling the key aspects of a software development to be captured on paper

Goals of UML by Ojo and Estevez, (2005) are to:

• Provide modelers with an expressive, visual modelling language to develop and exchange meaningful models 
• Provide extensibility and specialization mechanisms to extend core concepts 
• Support specifications that are independent of particular programming languages and development processes 
• Provide a basis for understanding specification languages 
• Encourage the growth of the object tools market \
• Supports higher level of development with concepts such as components frameworks or patterns

UML with Modelling

Modelling is the designing of software applications before coding (implementation in a particular programming language). A model is a representation or simplification of reality. It provides a blueprint of a system. A model does not dictate or show how the implementation will actually be done. It just shows what, who, which, where, when etc. Model-driven analysis and design emphasizes the drawing of pictorial system models to document and validate both existing and/ or proposed systems. Ultimately, the system model becomes the blueprint for designing and constructing an improved system.

Modelling is a central part of all the activities that lead up to the deployment of good software. We build models to: 

• Communicate the desired structure and behavior of our system. 
• Visualize and control the system's architecture. 
• Better understand the system we are building, often exposing opportunities for simplification and reuse. 
• Manage risk. 
• Modelling manages Complexity 
• Modelling Promotes Reuse

Modelling ensures that: 

• Business functionality is complete and correct, 
• End-user needs are met, and 
• Program design meets requirements for scalability, robustness, security, extensibility, and other characteristics, all these must be ensured before implementation in code

There are many elements that contribute to a successful software organization; one common thread is the use of modeling. Modeling is a proven and well-accepted engineering technique. There are three basic building blocks: Elements which are main "citizens" of the model, relationships i.e. relationships that tie elements together and Diagrams which are mechanisms to group interesting collections of elements and relationships. These elements are used to represent complex structures.

Principles of Modelling

The use of modeling has a rich history in all the engineering disciplines. That experience suggests four basic principles of modeling: 

(a) The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. In other words, choose your models well. The right models will brilliantly illuminate the most wicked development problems, offering insight that you simply could not gain otherwise; the wrong models will mislead you, causing you to focus on irrelevant issues. 

(b) Every model may be expressed at different levels of precision. 

The best kinds of models are those that let you choose your degree of detail, depending on who is doing the viewing and why they need to view it. An analyst or an end user will want to focus on issues of what; a developer will want to focus on issues of how. Both of these stakeholders will want to visualize a system at different levels of detail at different times.

(c) The best models are connected to reality. 

In structured analysis techniques there is a basic disconnect between its analysis model and the system's design model. Failing to bridge this break causes the system as conceived and the system as built to diverge over time. In object oriented systems, it is possible to connect all the nearly independent views of a system into one semantic whole.

(d) No single model is sufficient. 

Every nontrivial system is best approached through a small set of nearly independent models. To understand the architecture of object-oriented software system, you need several complementary and interlocking views: a use case view (exposing the requirements of the system), a design view (capturing the vocabulary of the problem space and the solution space), a process view (modeling the distribution of the system's processes and threads), an implementation view (addressing the physical realization of the system), and a deployment view (focusing on system engineering issues). Each of these views may have structural, as well as behavioral, aspects. Together, these views represent the blueprints of software.

Conclusion

The purpose of the Unified Modeling Language is to visualize, specify, construct, document and communicate object-oriented systems and it is gaining adoption as a standard language. The language provides the notations to produce models.

Source: Ellen Ambakisye Kalinga
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.