Modeling Activity Unified Modeling Language UML

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