Object-oriented technology is widely used in GIS research and software development. In addition to the advantages that object-oriented technology brings to software analysis and design, it also benefits the data modeling of GIS. This is the second of two lessons on object-oriented tools and techniques for geospatial system development. This lesson addresses the important skill of object modeling during systems design. Here you will learn about various unified modeling language (UML) diagrams and object-oriented design concepts. While object-oriented data models have been extensively used for modeling geographic applications, the models present limitations, since they do not provide appropriate primitives for representing spatial data. There are efforts to provide primitives for modeling the geometry and the topology of spatial data, supporting different topological structures, multiple views of objects, and spatial relationships. In this way, UML is being enhanced to overcome the limitations of the existing models, thus providing more adequate tools for modeling geographic applications.
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.)
To finish this lesson, you must complete the activities listed below. You may find it useful to print this page out first so that you can follow along with the directions.
Step | Activity | Access/Directions |
---|---|---|
1 | Read the lesson Overview and Checklist. | You are in the Lesson 12 online content now. The Overview page is previous to this page, and you are on the Checklist page right now. |
2 | Online material (Read) | There are three different styles of reading that are referred to in the lessons:
Geographic Markup Language [2] |
3 | Geospatial Think-Piece (Template) [3] |
Using Word (or a word processing program compatible with Microsoft® Word), identify and briefly discuss (<300 words): Why is UML described as a language? Name and discuss a geospatial concept that is or should be part of the UML language. Name your file Lsn12_YourName.doc, Please turn-in your document the Lesson 12 Dropbox in ANGEL. What is a “Think Piece”? A “think piece” is a form of writing that is less polished than a formal paper or presentation but more fully developed than an entry in a personal journal. Think pieces are written to discover what an individual is thinking about a particular topic. Within this course, the writing of think pieces is a way of helping learners connect with the subject matter. Within this context, think pieces reduce the grading risk associated with an “all or nothing” term paper and allow the instructor to communicate with learners throughout the semester, to see the evolution of thinking, and to suggest resources that can further the learners’ understanding. What does a Think Piece look like? The starting point for a think piece for this course lie in the author’s immediate past experience. Because think pieces are as much a reflection of one’s ideas, there is no standard or uniform format for a think piece. In other words, each of us is writing from personal experience. We are not claiming to be objective not are we offering prescriptive, how-to, formulas or guidelines. |
4 | Read lesson Summary. | You are in the Lesson 12 online content now. Click on the "Next Page" link to access the Summary. |
There was a time when GIS data was simply represented as points, lines, and polygons with attached attributes. As GIS continues to build on an Object Oriented (OO) technology, advancements in database design have expanded the simple storage of geometry and attributes to include object states, enhanced relationships, validation rules, connectivity requirements, and intricate geometric networking. As you should know by now, OOA&D (Object Oriented Analysis and Design) is a methodology for system design and data modeling, consisting of assessment, decomposition, conceptualization, and physical modeling techniques to meet the user's needs. Since it is user-centric, the OOA&D approach is incremental in nature, comprised of many reusable pieces or elements, which are created as needed, or when identified by the user. It is also iterative in nature, offering the flexibility of continuous or successive testing and revision throughout the entire process. This allows the user to test and register feedback as the functionality is explored or added, rather than during the final testing phase, as found in many of the older development methodologies.
The OOA&D approach is structured into a process of workflow procedures which progress through the phases of inception, elaboration, construction, and transition. Each phase contains specific tasks or activities that produce pieces of information, termed artifacts, which are created in incremental stages and refined through iterations or development cycles. UML (Unified Modeling Language) is a graphical notation language, used to visualize and store system objects, actions, and relationships in a sort of software blueprint fashion. The Unified Modeling Language (UML) is a simple and extensible modeling language. That does not dictate nor require that a particular process is followed, however, the developers of the language do encourage users to follow a use case driven, architecture-centric, iterative and incremental process that is object oriented and component based. It is a modeling language specification. Tools used to implement UML can range from pen and paper through to sophisticated off-the-shelf applications. The UML is not a visual programming language; it is a visual modeling language. It is not simply a notation, but a language for capturing knowledge and expressing knowledge about the system under design. UML has become the industry-standard language for system modeling. UML is not a process; UML is process independent.
UML diagrams provide many perspectives of a system during analysis and development. UML defines a set of graphical diagrams that are used for many planning, design and implementation tasks which depend upon the angle from which you are viewing the system. The major views of the system that UML supports are: 1) the user view, 2) the structural view, 3) the behavioral view, and 4) the implementation view. One or more diagrams for each view is defined by the UML and each provides a unique window into the system. UML diagrams are to be treated as a set of resources for system modeling. Take care to utilize only those diagrams that provide a useful and beneficial view of your system. The general order is: 1) use case diagrams, 2) structural and behavioral diagrams, 3) component diagram, and 4) deployment diagram. UML diagrams are briefly described below. You can also view the UML Diagrams Overview presentation [4] (PowerPoint).
Use Case Diagram. The user view provides a window into the system from the user's perspective, in that the functionality of the system is modeled in terms of the user and what the user expects of the system. In UML-ese, the user of the system is called an actor, which can represent either a human user or users as other systems. The functionality of the system is defined by the use cases. The lines connecting the actors and the use cases show that the actors interact with the functionality provided by the use case. Use cases are usually described in greater detail in Functional Requirements.
Business Use Case Diagram. The business use case diagram is an extension to the use case diagram and is defined in and supported by UML. The first step in business modeling using the UML is identifying the interactions between the business processes and those entities outside the business, such as customers and suppliers.
Class Diagram. Class diagrams describe the static structure of a system. The focus of the class diagram is to describe how a system is structured rather than how it behaves. Class diagrams are probably the most versatile of the UML diagrams. Data models, software components, software classes, and business objects are modeled using the class diagram, each in its own diagram.
The Sequence Diagram. Sequence diagrams describe the behavior of a use case by diagramming the classes and the messages exchanged between them, arranged in chronological order. Sequence diagrams do not describe object relationships; that view of the system is reserved for collaboration diagrams. Object and actor instances can be displayed in the sequence diagram along with how the objects communicate by sending messages to one another.
Collaboration Diagram. The collaboration diagram is a view of the interactions of objects and unlike the sequence diagram that describes the objects, messaging over time, collaboration diagrams display the relationships between objects. Some UML tools can automatically generate collaboration diagrams from sequence diagrams, and vice versa. Collaboration and sequence diagrams express similar information but they display it from different perspectives.
Activity Diagram. The activity diagram is a specialization of the state diagram and it displays the dynamics of a system by showing the workflow. The activity diagram complements the business use case diagram in that it shows the process flow behind the use case.
State Diagram. The state diagram describes the sequence of states that an object goes through during its lifetime. The state diagram displays the events that act upon the object that enables the transition from one state to the next.
Component Diagram. The component diagram displays the static structure of the implementation view. The component diagram shows the organizations and dependencies of the components, subsystems, and their relationships. The diagram models the interface that can be used to show the externally visible operations of a class or component.
Deployment Diagram. The deployment diagram shows the configuration of run-time processing elements and the software components, processes and objects that execute on them. The deployment diagram can be used for business modeling where employees and organizations are displayed as run-time processing elements and the procedures and documents that they use are displayed as the software components.
This lesson addressed the various unified modeling language (UML) diagrams and object-oriented design concepts and was the second of two lessons on object-oriented tools and techniques for system development. This addressed the important skill of object modeling during systems design. We discussed the models limitations of not providing primitives for representing spatial data and provided information of how UML is being enhanced to overcome the limitations of the existing models, thus providing more adequate tools for modeling geographic applications.
Links
[1] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/New_Lesson_12/Spatial%20OO%20design.ppt
[2] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/New_Lesson_12/GML_2.pptx
[3] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/Misc/Think-Piece%20Template.docx
[4] https://www.e-education.psu.edu/geog468/sites/www.e-education.psu.edu.geog468/files/UML.pps