Chapter 10 Textbook Notes

Activity Diagrams

- Show sequence of activities in a process

o Sequential and parallel

- Arrow = event
o Things happening at certain time/place
- Diamond = decision
- Long, flat rectangle = synchronization bar
o Show parallel activities
- Rectangles surrounding other symbols = swim lanes
o Partitioning

Creating Activity Diagrams

- Created by asking what happens first, second, etc.

- Sequence / parallel important
- Swim lanes can show how data is converted or created
o Need mechanisms for getting data across swim lanes
- Swim lanes can divide up tasks between a team
Sequencing Diagrams

- Illustrate succession of interactions between classes or object instances over time

- Used to illustrate processing described in use case scenarios
- Show overall pattern of activities or interactions of the use case
- One use case scenario = one sequence diagram
- During the systems design phase, sequence diagrams are refined to derive the
methods and interactions between classes.
- Vertical line
o lifeline for the class/object
o X on the bottom of the lifeline represents when the object is destroyed
- Lateral bar/vertical rectangle on the lifeline shows the focus of control when the
object is busy doing things
- Horizontal arrows
o Show messages or signals that are sent between the classes
- Solid arrows
o Synchronous calls (most common)
- Half (open) arrowheads
o Asynchronous call
o Menu to run a program
- Return shown as an arrow
- Timing is top to bottom
Communication Diagram

- Show same info as sequence diagram but more difficult to read

o To show ordering need to use seq # and describe message
- Describes the interactions of two or more things in the system that perform a
behavior that is more than any one of the things can do alone.
- Example
o Car can be broken down into several thousand parts
 Classes = parts
 Each have their own unique attributes
 Individual pieces form the car because they ‘communicate” with
each other
- Three parts
o Objects (participants)
o Communication links
 o Messages (that can be passed along those links)

Class Diagrams

- OO works to discover classes, attributes, methods, and relationships between

classes
- Programming occurs at the class level
- Class diagram shows the static features of the system and do not represent any
particular processing as well as shows the nature of the relationships between
classes.
- Class = rectangle
- Attributes are characteristics of an object
- Methods (operations) are what the class knows about how to do things
o Small sections of code that interact with attributes
 - Attributes are normally private or only avail for the obj
o Can also be protected #
o Hidden from all classes except immediate subclasses
o When they are hidden, they can only available t outside objects through
the class methods (encapsulation)

Method Overloading

- Including same method (operation) several times in a class

- Example
o Bank deposit slip could contain just the amount of the deposit (full
amount) or deposit amount and cash to be returned
o Both situations would use a deposit check method, but the parameters
would be different

Types of Classes

- Entity classes
o Real-world items
 People, things, etc.
o ER Diagram
 - Boundary (Interface) Class
o Means for users to work w/the system
o Human
 Display, window, dialog box, etc.
o System
 Sending data to or receiving data from other systems
 Databases
 XML (external)
- Abstract Class
o Cannot be directly instantiated
 instantiation is the creation of a real instance or particular
realization of an abstraction or template, such as a class of objects
or a computer process.
- Control Classes
o Used to control the flow of activities
o Use many small control classes to create reusable classes
o Often used to make another class reusable
o Example
 Logon process that wants to be reused

Defining Messages and Methods

- Like data dictionaries

- Definition would include a list of the parameters passed with the message as well
as the elements contained in the return message.

Enhancing Sequence Diagrams

- Include the actor from the use case diagram

- Define one or more interface classes for each actor
o Each actor should have their own interface class
- Create prototype web pages for all human interfaces
- Ensure that each use case has one control class
- Examine the use case to see what entity classes present
- To obtain a greater degree of reuse, consider moving methods from a control
class to an entity class
https://csulb-bookshelf.vitalsource.com/reader/books/9780134817378/epubcfi/
6/264[%3Bvnd.vst.idref%3DP700101467100000000000000000360F]!/
4/2[P700101467100000000000000000360F]/
8[P7001014671000000000000000003622]/6[P700101467100000000000000000F01E]/
11:33[s%5E%3B%20%2Cand]
 - Can be difficult to pass studentID, as an example
- Can store ID in the URL but bad for privacy
- Store ID in a cookie
- Use hidden web form fields
o Data sent by server but invisible

Presentation, Business, and Persistence in Sequence Layers

- Presentation layer
o What the users sees
o Contains interface or boundary classes
- Business layer
o Unique rules for the app
o Contains control classes
- Persistence (data access) layer
o Describes obtaining and storing data
o Contains the entity classes
- Ideally, program code would be written separately for each of these layers
- AJAX helps with rapid validation instead of waiting for web pages to load

Enhancing class diagrams

 - If the class is a user interface type of class, the attributes are the controls (fields)
on the screen or form. Methods would be those that work on the screen, such as
submit or reset
- If class is a control class, the attributes would be those needed to implement the
class, such as variables used in the control class. The methods would be used to
perform calculations, make decisions, and send messages to other classes
- If the class is an entity class, the attributes represent those stored fort he entity
and the methods working directly with the entity, such as creating a new
instance, modifying, deleting, obtaining, or printing.

Relationships

- Show relationships on the class diagram like an ER diagram

- Two types of relationships: associations and whole/party relationships

Associations

- Structural connection between classes or objects

- Line with multiplicity (cardinality in ER diagrams)
o 0..1 = zero to 1
o 1..* one to many
o 1..1 one to one
- No restrictions on the lower limit e.g. 5..* (min of five must present) and same
from upper limit
- Student may be able to enroll in 1 to 10 (1..10) courses)
- Can have relationship to other objects in same class (reflexive) e.g., employee
managing another employee
Whole/Part Relationships

- When one class represents a whole object and other classes present parts of that
object.
- Whole acts as a container for the parts
- Line with diamonds
o Human can exist without a hand, but not without a brain and heart
o Cannot be a boxer without both hands

Aggregation

- “has a” relationship
- Show that the whole object is composed of the sum of its parts (other objects)
- Weaker relationship not filled diamond
- Stronk relationship filled in diamond
- See example above

Collection

- Whole and its members

- Voting district with voters
- Voters may change, but the whole retains its identity
- Weak association
Composition

- A whole/part relationship in which the whole has a responsibility for the part
- Strong relationship
- Filled in-in diamond
- “Always contain” another class
- If the whole is deleted, all parts are deleted
- If you delete the human the boxer is also deleted
- If you delete the hands the boxer is also deleted
- Insurance policy gets cancelled then all insurance members of that policy are also
cancelled
- If a course is cancelled all assignments and exams are also deleted

Generalization/Specialization (Gen/Spec) Diagrams

- Enhanced class diagram

Specialization

- Subclass / child class

- Need to distinguish whether a koala bear is an animal or a type of animal

Generalization

- Car and truck are both vehicles

- Vehicle is the general thing
- Useful for inheritance and specialization
- Superclass

Inheritance

- Several class may have the same attributes or methods

- General class created to store common attributes
- Specialized class inherits or receives the attributes/methods of the general class
- Unique methods only used in the specialized class

Polymorphism

- Capability of OO program to have several versions of the same method with the
same name within a super/sub class relationship
- Subclass inherits method but can modify it like change type of data or how it
works
Abstract Classes

- General classes become abstract class

- No direct objects or class instances
- Used in conjunction with specialized classes
- Have attributes and may have a few methods
Identifying Abstract Classes

- Look at database tables to see if they have the same elements or if a number of
classes have the same methods
- Banking example
o Withdrawal, payment on a loan, check written will use same method –
subtracting money from customer’s account

Finding Classes

- Interview, JAD, team sessions, brainstorming, analyzing docs/memos, etc

- Nouns may become classes
o Candidate classes
- Each class should exist for a distinct object that has a clear definition
- Can create associative classes for a many-to-many relationship

Determining Class Methods

- Some methods are standard such as new() <<create>>

- Use CRUD to determine activities
- Create = new()
- Update = update() or change(0
- Delete = delete() or remove()

Statechart Diagrams

- Another way to determine class methods

- Examine the different states than an object may have
- Created for single class
- Objects go through changes and are deleted/removed
o Conditions of an obj at specific time
o Order status
- States have entry/exit actions
- An event is something that happens at a specific time and place
o Cause change of the object state
- States separate events
- Event causes transition and happens when guard condition met
- Guard condition
o Something that evaluates to either true/false
 Click to confirm order
- Event categories
o Signals or asynchronous messages
 When calling program does not wait for returning message, such as
a feature run from a menu
o Synchronous messages
 Functions / subroutines
 Calling object stops and waits for control to be returned to it
o Temporal events
 Predetermined time
 Do not involve actor/external event
- Material objects have persistence
o Airline flights, cocnernts
- Each time an ob changes state some of the attributes change their values
o Must use methods to change attributes
 - Statecharts not created for all classes
- Created when
o Class has a complex life cycle
o An instance of a class may update its attributes in a number of ways
throughout the life cycle
o A class has an operational life cycle
o Two classes depend on each other
o The object’s current behavior depends on what happened previously
- Should have one state in and out of it

Packages and other UML Artifacts

- Use cases can be grouped together

- Component diagram
o Like a class diagram
o Bird’s eye view of sys architecture
- Development diagram
o Physical implementation of the sys
o Hardware/relationships between hardware
o Servers, workstations, etc.

Putting UML to work

- Define use case model

- Continue to UML diagramming to model the system during the systems analysis
phase
- Develop the class diagrams
- Draw Statechart diagrams
- Begin systems design by refining UML diagrams to derive classes and their
attributes and methods
- Document the system in detail

READ THIS FOR EXTREME DETAILS

https://csulb-bookshelf.vitalsource.com/reader/books/9780134817378/epubcfi/
6/272[%3Bvnd.vst.idref%3DP7001014671000000000000000003973]!/
4/2[P7001014671000000000000000003973]/
6[P700101467100000000000000000F33A]/
10[P700101467100000000000000000F363]/
4[P700101467100000000000000000F365]