PrintThis lesson is an introduction to UML or, more properly, the Unified Modeling Language. The Unified Modeling Language (UML) was developed during the 1990s, starting with Rational Software Corporation and three prominent individuals in the information technology industry, Grady Booch, James Rumbaugh, and Ivar Jacobson. UML is becoming the standard for building Object-Oriented software and databases. The language has achieved industry support through the UML Partners Consortium and is approved standard of the Object Management Group (OMG).
The entity-relationship diagram (ERD) is, in fact, the grandfather of ULM. Developed in the 1970s, ER modeling was created to provide a diagramming notation that could directly map to a relational database schema. As the definitions of entities, attributes, and relationships have become more sophisticated, we refined our data modeling methods. Although ER modeling was essential to the development of UML, the focus on a graphical notation that helped database designers better understand the problem space has changed to the discovery and representation of the users' needs.
Most new GIS development tools emphasize object-oriented (OO) features and therefore suggest that an OO analysis and design (OOAD) methodology is appropriate. What is different about an OOAD? According to Donald Firesmith in the Dictionary of Object Technology (SIGS Books, 1995), analysis is "the development activity consisting of the discovery, modeling, specification and evaluation of requirements," while OO analysis is "the discovery, analysis and specification of requirements in terms of objects with identity that encapsulates properties and operations, message passing, classes, inheritance, polymorphism and dynamic binding." Firesmith states further that OO design is "the design of an application in terms of objects, classes, clusters, frameworks, and their interactions."
When comparing the traditional analysis with that of OOAD, the only aspect that differs is classifying a problem in terms of objects and object classes. A class is any uniquely identified abstraction of a set of logically related instances that share the same or similar characteristics. An object is any abstraction that models a single thing, and the term "object" is synonymous with instance. Classes have attributes and methods. For an object class named Roads, attributes might be Name and Width, and methods might be Update and Delete. The class definition defines the Roads class attributes and methods, and a real road, such as "Main Street", is an instance of the class. If you have different kinds of roads, such as Interstate Highways and Local Roads, you can create two new classes of roads that are descendants of the Roads class. These descendants use inheritance to gain access to all of the Roads class attributes and methods, but can override any of the ancestor attributes and methods, as well as contain any required new attributes and methods. There are three types of relationships between classes: inheritance, aggregation, and association. Inheritance (also referred to as generalization/specialization) is usually identified by the phrase "is a kind of."
The UML is neither a software development methodology nor a systems development life cycle. It is simply a notation for documentating a system design. UML simply provides a standardized means of visualizing, specifying, constructing, and documenting software and data systems. It allows the designer to evaluate business processes, system functions, software components, and database schemas. In other words, it is the language that the blueprint for a system is written in. UML defines the notation and meanings for the following areas:
- Use Case Models which describe the boundary and interaction between the system and users.
- Collaboration Models which describe how objects in the system will interact with each other to get work done.
- Dynamic Models where state charts describe the states or conditions that classes assume over time. Activity graphs can be used to describe the workflows the system will implement.
- Logical Models which describe the classes and objects that will make up the system.
- Physical Component Models which describe the software of the system.
- Deployment Models which describe the physical architecture and the deployment of components.
As you can see, UML is quite extensive and describes the whole system including software and hardware.
Lesson Learning Objective:
- Develop an understanding of the methods and tools associated with documenting and evaluating a design
Questions?
If you have any questions now or at any point during this lesson, please feel free to post them to the Threaded Discussion Forum. (That forum can be accessed at any time by clicking on the Communicate tab, above, and then scrolling down to the Discussion Forum section.)