This 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:
As you can see, UML is quite extensive and describes the whole system including software and hardware.
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 10 online content now. The Overview page is previous to this page, and you are on the Checklist page right now. |
2 | There are three different styles of reading that are referred to in the lessons:
|
|
3 | View the Lesson Overview. | You are in the Lesson 10 online content now. Click on the "Next Page" link to access the Lecture/Discussion. PowerPoint [1]. |
4 | Geospatial Think-Piece (Template) [2] |
Using Word (or a word processing program compatible with Microsoft® Word), briefly discuss (<200 words): why "model" a system? Name your file Lsn10_YourName.doc, Please turn-in your document the Lesson 10 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. |
5 | Next Class | Each team will bring to class a document containing their project's:
|
6 | Read lesson Summary. | You are in the Lesson 10 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 work flow 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 we will discuss in more detail in a later lesson. This discussion is just a brief introduction. UML 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 depending on the angle that 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. Some UML diagrams are more critical than others for system modeling. 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.
Use Case Diagram. The user view provides a window into the system from the users 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 work flow. 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 taught the important skill of object modeling during systems analysis. You learned about the unified modeling language (UML) diagrams and built the ones that apply to systems analysis.