1. Introduction to Entity-Relationship Diagrams, Data Flow Diagrams, and UML
Todd Bacastow Penn State University Geography 583 Geospatial System Analysis & Design

2. Data Modeling
Data modeling – a technique for organizing and documenting a system’s data. Sometimes called database modeling.
Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data.
No additional notes

3. Data Modeling Concepts: Entity
Entity – a class of persons, places, objects, events, or concepts about which we need to capture and store data.
Named by a singular noun
Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier.
Places: sales region, building, room, branch office, campus.
Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle.
Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip.
Concepts: account, block of time, bond, course, fund, qualification, stock.
Teaching Notes:
Prompt the students for additional examples. Have them classify their example(s).
Obtain a data model from a source other than the textbook. Ask the students to classify the entities.

4. Data Modeling Concepts: Attributes
Attribute – a descriptive property or characteristic of an entity. Synonyms include element, property, and field.
Just as a physical student can have attributes, such as hair color, height, etc., data entity has data attributes
Compound attribute – an attribute that consists of other attributes. Synonyms in different data modeling languages are numerous: concatenated attribute, composite attribute, and data structure.
Teaching Notes:
Go back to the slide showing the sample ERD (Figure 8-1). Pick an entity and ask the students to list attributes that they feel describe those entities.
Show the students a form. Ask the students to identify the attributes. Be sure that the students recognize what items appearing on the form are truly attributes and those that are simply headings or preprinted items. Also, often students accidentally identify attribute values as attributes. For example, they may say that an item that appears as a check box is an attribute when in fact it may be the value of an attribute (ie. Male and female are values, whereas GENDER is the real attribute).

5. Data Modeling Concepts: Identification
Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.
Concatenated key - group of attributes that uniquely identifies an instance. Synonyms: composite key, compound key.
Candidate key – one of a number of keys that may serve as the primary key. Synonym: candidate identifier.
Primary key – a candidate key used to uniquely identify a single entity instance.
Alternate key – a candidate key not selected to become the primary key. Synonym: secondary key.
Teaching Notes
Students can generally relate to the following example. Suppose you are working for an hourly wage. The employer has some method of tracking the hours you work. Whether that involves a time clock, an identification badge that it scanned, or a log book, the system records a certain number of hours and some employee identifier that says those hours are yours. Without that identifier, come pay day the employer would not know whose hours were whose. The employer might pay someone else for the hours you worked. That’s how important a primary key or identifier is.

6. Data Modeling Concepts: Relationships
Relationship – a natural business association that exists between one or more entities.
The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities.
Teaching Notes
Explain that there may be more than one relationship between two entities. You may reinforce this by adding additional relationships to the example (such as “transferred from” (to reflect a relationship where students changed from one curriculum to another).

7. Data Modeling Concepts: Cardinality
Cardinality – the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity.
Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship.
Teaching Notes
Ask the students to read (or write) declarative sentences to reflect the bidirectional meaning of the relationship between student and curriculum.
bidirectional

8. Data Modeling Concepts: Degree
Degree – the number of entities that participate in the relationship.
A relationship between two entities is called a binary relationship.
A relationship between three entities is called a 3-ary or ternary relationship.
A relationship between different instances of the same entity is called a recursive relationship.
Teaching Notes:
Provide the students with an ERD that does not contain relationships. Ask the students to identify possible relationships and indicate a possible degree for that relationship.
Emphasize to the students that the degree represents a business rule! Failure to accurately identify and document the degree will result in a system that does not reflect a correct business requirement.

9. Why Logical System Models
Logical models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results.
Logical models allow us to communicate with end-users in nontechnical or less technical languages.
No additional notes

10. Process Modeling and DFDs
Process modeling – a technique used to organize and document a system’s processes.
Flow of data through processes
Logic
Policies
Procedures
Data flow diagram (DFD) – a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model.
The DFD has also become a popular tool for business process redesign.
Teaching Notes
Many, if not most students have drawn or seen process models in the form of program flowcharts.
Unfortunately, flowcharts are control-flow process models as opposed to data flow process models. This can cause some students trouble because they want to illustrate structured flow of control (nonparallel processing) in their early DFDs.
Most introductory information systems books at least introduce, with one or two examples, DFDs.

11. Differences Between DFDs and Flowcharts
Processes on DFDs can operate in parallel (at-the-same-time)
Processes on flowcharts execute one at a time
DFDs show the flow of data through a system
Flowcharts show the flow of control (sequence and transfer of control)
Processes on a DFD can have dramatically different timing (daily, weekly, on demand)
Processes on flowcharts are part of a single program with consistent timing
No additional notes

12. What is the UML? Unified Modeling Language
It is a modeling language, not a process
In 1996, work on the UML was begun by Rational.
Where to Find Out More

13. UML Diagrams Class Diagrams Use Case Diagrams Collaboration Diagrams
Sequence Diagrams
Package Diagrams
Component Diagrams
Deployment Diagrams
Activity Diagrams
State Diagrams
Types of UML Diagrams

14. Class Diagrams Are the most fundamental UML Diagram.
Describe the classes in the system, and the static relationships between classes.
Class diagrams are used during Analysis, Design and Development.
Class Diagrams
Class diagrams that appear during the Analysis phase generally describe user interface and related classes. In UML Distilled read the description of class diagram perspectives located on page 65. Most of the class diagrams will be generated during Design. Some may be generated during early Development, and classes will often be modified during Development. Static relationships are relationships between classes (which can be thought of as object templates).

15. UML Class Diagram 1 1..* 1 0..1 1 What is a Class Diagram? Customer
Rental Invoice
Rental Item
1..* 1
0..1 1
What is a Class Diagram?
Checkout Screen
DVD Movie
VHS Movie
Video Game
This class diagram shows examples of associations, aggregations, and generalizations. In general, associations describe the relationships between classes or objects. They start as simple connectors, to show that some relationship exists. As design progress the natures of the relationships become clearer, and the associations are modified to reflect the new knowledge. For example, direction and cardinality are usually added later in design. The diagram above shows a generalization relationship between several kinds of objects. Generalization means here that the specializations of Rentable Item are fully consistent with Rentable Item and may be used wherever Rentable Item is allowed.

16. UML Class Diagram 1..* 1 0..1 What is a Class Diagram? DVD Movie
VHS Movie
Video Game
Rental Item
{abstract}
Rental Invoice
1..* 1
Customer
Checkout Screen
0..1
Simple
Association
Class
Abstract
Aggregation
Generalization
Composition
(Dependency)
Multiplicity
What is a Class Diagram?

17. -- can optionally be described here.
Parts of a Class
Classes can have four parts
Name
Attributes
Operations
Responsibilities
Classes can show visibility and types.
All parts but the Name are optional.
MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()
Responsibilities
-- can optionally be described here.
The Parts of a Class
An individual class is shown on the diagram as a box with up to four sections.
The first section shows the name of the class. Names should be nouns. Typically the first letter of every word in a name is capitalized.
Attributes represent the state of the object or what the object knows.
Operators represent the behavior of an object or what the object does.
Responsibilities are optional. A Responsibility is a contract or an obligation of the class. They are normally only used in analysis and early in the design phase to describe what a class should do without describing how it should do it.
The + sign indicates that an attribute or operation is public or visible to all other objects or operations in the system.
The - sign indicates that an attribute or operation is private or hidden from any objects or operations other than those objects also of the current class.
The # sign indicates that an attribute or operation is protected or visible only to members of the same class or members that are specialization's of (or derived from) that class.

18. Object Diagrams Described
An Object is an instance of a class.
Object names are underlined.
Object diagrams are similar to class diagrams. Many of the same notations are used.
Object diagrams capture instances of classes, and allow the dynamic relationships to be shown.
ThisOne : MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()
Object Diagrams Described
Object diagrams have a very similar appearance to class diagrams (see next slide), but are more specific. It is very important to make sure the syntax rules for writing the names of classes and objects are followed. Otherwise, confusion is sure to result.
Object diagrams are useful when information about the dynamic relationships between classes must be captured.
Dynamic relations are between instances (of classes). If a particular person (Bob) rents a particular movie (Casablanca), there is a dynamic relationship between Bob:Person, and Casablanca: Movie. Compare to static relationships (defined on the previous slide).

19. Class and Object Diagrams
Class Name
Association Name
Customer
Rental Item
+id:integer
Rents
0..n
+id:integer
+name:string
+released:date
0..1
Class Diagram
Attributes
Object Name
Joe: Customer
Casablanca: Movie
Class Diagrams and Object Diagrams
+id:1667
+id:22340
+name:Joe Smith
+released:1942
Note that the object diagram is much more specific. Values are provided for data. The relationship is less abstract, because it refers to the relationship between two instances (here, ‘Joe’ and ‘Casablanca’), and not the theoretical relationship between classes.
The UML specification requires that object names be underlined. Objects do not need to be named, but if an object does not have a name, the name of its class must be preceded with a colon. This makes clear that the name represents a class and not an object. In the diagram above, “:Customer” could also be used. Class names are also not required; if the class name is not provided, there should not be a colon. In the diagram above, ‘Joe’ could also be used. Obviously, each object should have either a name or a class name.
Be careful when simplifying diagrams by removing names -- ensure that you have not removed vital information. If ‘Joe’ could be an instance of any of a number of related classes, it may be important to show which class it is. The idea is to strike the right balance between a diagram that captures the needed information, and one that’s not so cluttered the eye cannot follow the concepts.
Object Diagram

20. Use Cases
Describe interactions between users and computer systems (both called actors) .
Capture user-visible functions.
Achieve discrete measurable goals.
Are typically used during Analysis and Design.
What is a Use Case?
A use case model is important for visually representing a system, but equally important is the text that supports the use case model, called the Use Case Report. The elements of the Use Case Report will be discussed in later slides.
A use case is initiated by an actor to perform a required task.
Most of the time, an actor is a person, but that doesn’t have to be the case. Sometimes, an actor can be another computer system -- for example, when an external system requires a roll-up report for processing, one might view that system as an actor, and the generation of that roll-up report as a use case.

21. Use Case Diagram for the Movie Store
Telephone
Customer
In-Store
Clerk
Identify Movie
Open Account
Return Movie
Review
Account Status
Actor
Use Case
Use Case Diagram for the Movie Store
An actor is someone or something that initiates use cases. It is stereotyped from a class.
A use case is a sequence of actions performed at the request of an actor. A use case contains all the actions that can occur between an actor-use case pair. In a given scenario, some actions may not occur. A use case contains a set of scenarios that explain various sequences of interactions within it.
An association represents a semantic connection between an actor and a use case. Associations are uni-directional; they are the most general of all relationships and the most semantically weak. A stereotype can refine the association.
A generalization relationship can show actors that share behavior (perhaps several actors can function in role; that role can also be an actor which defines the common behavior).
Diagram Notes:
The use cases here are: Identify Movie, Open Account, Return Movie, and Review Account Status.
The actors are: Customer and Clerk. The Customer is the parent actor and the In-Store and Telephone Customer are child actors. The child actors inherit some of their characteristics from the parent actor.
The Customer can initiate the Identify Movie, Open Account, and Return Movie use cases; the Clerk (or any of its specializations) can initiate any of the use cases.
Identify Movie names the movie the customer is looking to rent. The clerk will also need to identify the movie in the movie database or on the shelves in the store.
Open Account allows the customer and clerk to establish an account.
Return Movie explains that the customer brings the movie back to the store and the clerk puts the movie back in the database as “available” and places the movie on the shelf.
Review Account Status is only initiated by the clerk. It allows the clerk to review information not generally available to (or needed by) the customer.

22. What is a Use Case Report?
The Use Case Report provides documentation for the Use Case.
A Use Case is not complete without the report.
The elements of the Use Case Report are shown on the right.
Brief description
Precondition
Flow of events
Main flow
Subflows
Alternate flows
Postcondition
Special Requirements
Enclosures
Diagrams
Pictures of the UI
What is a Use Case Report?
The purpose of a Use Case Report is to describe the flow of events specifically in a way the customer understands.
1. Brief description-should describe the purpose of the use case in a few sentences. The actor that initiates the use case can be documented here.
2. Precondition-a precondition is a constraint on the system or indicates another task or use case that must be completed before beginning the use case being documented.
3. Flow of events-should describe when the use case begins, when it ends, where different actors take part in the flow of events, and the information exchanged. The main flow does not describe how problems are solved or the details of the UI. Each use case should start with, “This use case begins when….”
Main flow-is the normal sequence of events for the use case, what normally happens if nothing goes wrong.
Subflow-these are optional or parallel sequences, or large segments of a given flow of events that divides the flow of events into different sections. Provide a title for the subflow in your documentation and describe the order of subflows.
Alternate flow-an exceptional flow, the “what happens if” part of the main flow. Alternate flows specify variants to the main flow, optional flows, or error cases. Define a condition and the behavior for the alternate flow.
4. Postcondition-defines a constraint on the system when the use case has terminated.
5. Special requirements-non-functional requirements that may influence design.
6. Enclosures-the actual use case diagram, and possibly screen captures of the UI.

23. Collaboration Diagrams
Collaboration diagrams describe interactions and links
Focus on exchange of messages between objects
Appears during Analysis phase
Enhanced during Design phase
What is a Collaboration Diagram?
Class roles represent roles that object may play within the interaction. Association roles represent roles that links may play within the interaction. Message flows represent messages sent between objects via links. Links transport or implement the delivery of the messages.
Another view of the sequence diagram.
Collaboration diagram tend to provide the big picture for a scenario, organized around the object links to one another.

24. Collaboration Diagram - Rent Movie
:Check-out Manager
:Customer
:Inventory
1: enter_customer()
3: enter_movies()
5: add(customer, movies)
7: print invoice()
2: IsValidCust(CustId)
4:GetMovieByBarcode()
:Clerk
Object
Message
:Rented Items
8: generateRentalTotal()
A Collaboration Diagram for the Movie Store
The objects in rectangles represent class roles. The links (lines or paths) represent association roles. The arrows between class roles indicate message flows exchanged between objects. The message flows are labeled with both the sequence number of the message and the message that is sent between the class roles. A message triggers an operation in the receiving object. The sequence numbers indicate the sequence of messages within the next higher level of nesting.

25. What is a Sequence Diagram?
Sequence Diagrams
Can be “morphed” from Collaboration Diagrams.
Describe interactions between objects arranged in time sequence
Focus on objects and classes involved in the scenario and the sequence of messages exchanged
Associated with use cases
Used heavily during Analysis phase and are enhanced and refined during Design phase
What is a Sequence Diagram?
Interactions are modeled as exchange of messages. Class roles represent roles that objects may play within the interactions. Lifelines represent the existence of an object over a period of time. Activations represent the time during which an object is performing an operation. Messages represent communication between objects.
An object in a sequence diagram is drawn as a rectangle containing the name of the object, underlined.
It is easy to read and understand sequence diagram as it looks at a scenario based on time order. This diagram is very useful in the early analysis phase.

26. Sequence Diagram - Rent Movie
1: find customer()
2: search (string)
4: search (string)
6: add(Cust, item)
3: enter movie()
5: rent (movie)
7: printInvoice()
8: generateRentalTotal()
Object
Lifeline
Activation
Message
:CheckoutMgr
:Inventory
Cust:Customer
:RentedItems
:Employee
A Sequence Diagram Example
Depicts how the classes within the system work together. The objects at the top represent class roles. The dashed lines that extend from each object represent lifelines. The thin rectangles on the lifelines represent activations. The horizontal arrows between lifelines indicate the messages exchanged between objects. The horizontal arrows are labeled with the message that is sent between the class roles. The message triggers an operation in the receiving object.
The objects defined inside the rectangle can be defined in one of the three ways:
The object name, the object name and its class, or just the class name (anonymous object)

27. What is a Package Diagram?
Class
Package
What is a Package Diagram?
Packages are a grouping mechanism. A package can contain any other UML construction, including other packages. Packages are useful when producing diagrams that show a larger picture of the system.
This package diagram is a fragment of the “Clerk’s User Interface”. The package contains a Customer Data class and a Business System façade package. It also contains a Rental Screen class, and shows that the Rental Screen class depends on the Customer Data class and the Business System façade.

28. What is a Component Diagram?
Interface
Dependency
Note
What is a Component Diagram?
A component diagram shows software components, and their dependencies. It is a way of describing the structure of the code. Components are physical entities; they represent the implementation of the logical architecture described by class diagrams, object diagrams, and interaction diagrams.
Components can be:
Source: some source code; a compilation unit. Meaningful at compile time. Stereotypes such as «file», «page», and «document» can provide additional information about the component’s nature.
Binary: object code, or a library file (static or dynamic). Meaningful at link or runtime (this will depend on the specific nature of the component). The stereotype «library» appears here.
Executable: executable code; an image. Meaningful at execution time. These at the only variety of component that can have instances (while they are running). The stereotypes «application» and «table» (a database table viewed as a runtime component) are common on this sort of component.
Components are types. To show instances of components, one draws a deployment diagram and allocates instances of executable components to the nodes where they run.

29. What is a Deployment Diagram?
Node
Communication
Association
What is a Deployment Diagram?
A deployment diagram shows the runtime architecture of the system and the topology (physical architecture) of the system. Each node represents a piece of hardware. A node is a special kind of class; the detailed capabilities of the node can be represented as attributes and/or properties of that class.
Nodes are connected by communication associations. These are typically directionless associations that are stereotyped (as in the diagram above) to show what kind of traffic they carry.
Components may be placed inside of nodes. This shows that the component runs on the node. A diagram which shows how nodes are connected may not have this level of detail, but a diagram that fully describes a node should. Packages containing components can also be used to simplify the diagram. Objects (instances of classes) can also be drawn in nodes, if appropriate. They can be drawn inside the component that implements them if desired, or they can be drawn standalone (the relationship between an object and the component that implements need not appear in a deployment diagram).
A component can be shown to depend on a node, with the stereotype «supports». This indicates that the node supports instances of the component (this is not shown in the diagram above).
Because nodes are classes, more complex relationships (including cardinality) are certainly possible. They can be associated in any way that is legal for classes (but some associations may not be useful).

30. Activity Diagram Identify Caller Obtain Name & Address Create Account
Start State
Identify
Caller
Action State
Obtain Name
& Address
Decision
Open
Account?
Current
Customer?
[no]
[no]
[yes]
[yes]
End State
Activity Diagrams:
Are used in the Analysis and Design phases of ProVision.
Can show sequence in use cases and are similar to workflow diagrams.
Can show concurrency through parallel flows.
Allow multiple start points and conditional branching. Multiple start points can show relationships between different Use Cases.
Focus on flows driven by internal processing.
Apply to situations where all or most of the events represent the completion of internally-generated actions (the flow of control from activity to activity).
Can show how an object changes state at different points in the flow of control.
Create
Account
Diagram Notes:
1. The activity begins when the clerk identifies a caller either over the phone or at the counter.
2. The clerk will ask for identification by name and address.
3. The clerk looks in the database to determine if the customer is a current customer.
4. This is where the decision icon factors into the diagram. If the customer is a current customer, conclude the activity. If the customer is not a current customer, ask the customer if they would like to create an account.
5. The create account is another decision icon. If the customer wishes to create an account, continue with the flow and create an account. If the customer says no, conclude transaction (assuming the Movie Store rents only to account holders).

31. Swimlanes and Fork/Join Points
Customer
Manager
Walking Clerk
Identify
Movie
Fork Point
Place
Order
Place
Order
Fill
Order
Pay
Collect
Money
Swimlanes:
Swimlanes organize actions by class. Each swimlane is divided by classes or actors. Each swimlane represents the responsibility of the overall class, the ordering has no significance. Transitions may cross swimlanes.
Fork/Join Point:
Fork point-this shows where the thread or path divides into two parallel paths. There is no limit to the amount of threads coming out of a fork point. These threads will need to synchronize, which happens at the Join Point. Threads join back together at the join point. The activities below the fork point and above the join point occur in parallel.
Pickup
Movie
Deliver
Movie
Join Point
Diagram Notes:
1. The first action is a Customer checking to see if a movie is available.
2. The Customer orders the movie.
3. The Manager places the order using the movie database. (fork point)
4. The Walking Clerk obtains the order from the back while the customer is paying. (join
point)
5. The Walking Clerk delivers the order back to the Manager.
6. The Manager hands the movies to the customer.
7. The Customer picks up the order.
8. The activity terminates.

32. State Diagram What is a State Diagram? Guard Event Transition Action
Activity
What is a State Diagram?
State
This is a simple example of a state diagram that describes the video check-out process. UML State Diagrams are very similar to state diagrams seen in other design notations.
The diagram contains states and transitions.
Each state contains a name, and may also have associated actions. Actions are tasks (typically of a longer duration, and that can be interrupted by events). Actions start when the state is entered. A transition does not occur when an action completes; only an Event (see below) can cause a transition (however, an Event might occur as a result of tasks performed by the Action).
Each transition is labeled; the label consists of three parts, all optional: Event [Guard] / Action. The event is what triggers the transition; a transition cannot occur until its controlling event does. The guard is a Boolean expression that describes a condition -- the transition does not occur unless the condition is true (there can, in fact, be several transitions on the same event, with different guard conditions, as long as the guard conditions are mutually exclusive). Finally, the activity is a short, uninterruptible task.
Two “special” events exist. These are entry and exit. If they are defined, and association with Activities, those Activities occur immediately on entry (before any actions) and immediately on exit, respectively. This is true for all transitions into and out of the state. Exit occurs before any activity associated with the transition, and entry (on the new state) occurs after. Entry activities occur before state actions.

33. How does ProVision use the UML?
UML Diagram Usage
How does ProVision use the UML?

34. Conclusion
UML is a robust notation that can express information gathered throughout a project’s lifecycle.
Adopting standard use of UML can improve communication between clients and developers.
UML can be used as an effective data modeling tool as well as an object modeling tool.