PrintThere 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.
The User View
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.
The Structural View
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 Behavior View
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.
The Implementation View
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.