J.E.D.I
2.4 Unified Modeling Language UML
The Unified Modeling Language UML is the standard language for specifying, visualizing, constructing, and documenting all the work products or artifacts of a software system. In
the earlier days, UML has different terminologies as shown in Table 3.
UML Class
Association Generalization
Aggregation
Booch Class
Uses Inherits
Containing Coad
Class Object Instance
Connection Gen-Spec
Part-whole Jacobson
Object Acquaintance
Association Inherits
Consists of Odell
Object Type Relationship
Subtype Composition
Rambaugh Class
Association Generalization
Aggregation ShlaerMellor Object
Relationship Subtype
na
Table 3 Different UML Terminologies
However, its notation was unified by Booch, Rambaugh and Jacobson. The Object Management Group maintains a set of standards for using UML for technical exchange of
models and design. Now, other contributors augments the definition of UML.
UML is not a method or methodology. It does not indicate a particular process. It is not a programming language. It is basically a standard set of modeling tool used to
develop work products of the software, which most of it will be models.
2.4.1 Modeling Activity
Software development is a complex activity; it is extremely difficult to carry out the necessary task if all details are in ones memory. In any development project that aims
to produce useful work products, the main focus of both analysis and design activities is on models. A model is a pattern of something to be made. It is both abstract and
visible. Software is not tangible for the users and by nature, are abstracts. However, it is constructed by a developing team who need to see each others model.
A model is a representation of something in the real world. They are useful in a variety of ways because they differ from the things that they represent. Particularly, they are:
• built quicker and easier than the real objects they represent. • used in simulation to better understand the thing they represent.
• modified to evolve as one learns about a task or problem.
Software Engineering 48
J.E.D.I
• used to represent details of the models that one chooses to see and others ignored; they are basically an abstraction of the real objects.
• a representation of real or imaginary objects in any domain. A useful model has just the right amount of detail and structure, and represents only
what is important for the task at hand. Usually, developers model complex situation within a human activity system. They need to model what different stakeholders think
about the situation. Therefore, they need to be rich in meaning. The models of the analysis phase requirements and analysis model must be accurate, complete and
unambiguous. Without this, the work of the development team will be much more difficult. At the same time, it must not include premature decisions about how the
system is built to meet users requirements. Otherwise, the developing team may later find their freedom of actions to restricted. Most models are in the form of diagrams
that are accompanied by textual descriptions, and logical or mathematical specifications of processes and data.
Systems analysts and designers use diagrams to create models of systems. Diagrams are used extensively in order to:
• understand object structures and relationships. • share ideas with others
• solicit new ideas and possibilities • test ideas and make predictions
There are a lot of modeling techniques that can be found. Some general rule are listed below. Modeling techniques should be:
• Simple. Show only what needs to be shown. • Internally consistent. Diagrams should support one another.
• Complete. Show all that needs to be shown • Hierarchically Represented. Break down the system into smaller components.
Then, show the details of the lower-level. The Unified Modeling Language UML provides a set of modeling diagrams used for
modeling systems. The diagrams are composed of four general elements. • Icons. They represent the atomic symbols of the diagrams. They are
abstract shapes that are connected to other shapes. • Two-dimensional Symbols. They are similar to icons except that they have
compartments that can contains other symbols, icons or strings. Icon do not contains other symbols.
• Paths. They represent the link from one icon or symbol to another. They, normally, represent the flow from one shape to another.
• Strings. They are used to represent labels, descriptions, names etc. of icons, symbols and paths.
The UML Specification provides a formal definition of how to use UML Diagrams. It provides the grammar of UML syntax which includes the meaning of the elements, and
the rules of how the elements are combined semantics.
A single diagram illustrates or documents some aspect of a system. A model, on the other hand, provides a complete view of a system at a particular stage and from a
Software Engineering 49
J.E.D.I
particular perspective. For example, the models developed during the analysis phase give a complete view of the system from a problem domain. It tries to capture
essentially the what-aspect of the system such as what functions, what data etc. It will consists of several diagrams to cover all aspects of the problem domain. The models,
developed during design phase, gives a complete view of the software system to be built. It is a view coming from the solution domain. It will probably consists of diagrams that
represents components of the software such as dialog designs for the screens, database elements, controller functions etc.
The models that are produced during the project development changes as the project progresses. Normally, they change in terms of:
• Level of Abstraction. As the project progresses, the model would be come less abstract and be more concrete. For example, one may start off with classes
that represent the kind of objects that we will find in the system such as athletes, coach, squad and team. By the time, one gets to the end of the
design, one can already implement the classes with attributes and operations. The classes would also have additional supporting classes such as brokers,
proxies for the target deployment platform.
• Degree of Formality. The degree of formality with which operations, attributes and constraints are defined will increase as the project progresses. Initially,
classes and attributes may be loosely defined using Structured English or whatever language is used by the development team. By the time it reaches
the end of the design and ready for implementation, attributes and operations are defined using the target programming language such as Java. For
example, at the analysis phase, one uses athlete as the name of the class. At the design phase, it can be a persistent class holding information about an
athlete and be named as DBAthlete class.
• Level of Detail. As the project progresses, the different models represents the same view but shows a different level of detail. The models get more
details as it progresses through the development process. For example, the first use-case diagram may show only the obvious use-cases that are apparent
from the first iteration. At the second iteration, the use-case diagram may be elaborated with more detail, and additional use-cases may emerge. After the
third iteration, it may include more structured description on how users will interact with the use-cases and with relationships with other use-cases.
Any phase of the project will consists of a number of iterations, and that number will depend on the complexity of the system being developed. As the project progresses, the
level of abstraction, degree of formality and level of detail should be established properly so that work products will be useful.
Software Engineering 50
J.E.D.I
2.4.2 UML Baseline Diagrams