Class Diagrams

1
Class Diagrams
TariffSchedule
Trip
Enumeration getZones() Price getPrice(Zone)
zoneZone pricePrice

• Class diagrams represent the structure of the
  system.
• Class diagrams are used
• during requirements analysis to model problem
  domain concepts
• during system design to model subsystems and
  interfaces
• during object design to model classes.

2
Classes
Name
Signature
Attributes
Operations

• A class represent a concept.
• A class encapsulates state (attributes) and
  behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information.

3
Instances
tariff_1974TarifSchedule
zone2price 1, .20,2, .40, 3, .60

• An instance represents a phenomenon.
• The name of an instance is underlined and can
  contain the class of the instance.
• The attributes are represented with their values.

4
Actor vs. Instances

• What is the difference between an actor and a
  class and an instance?
• Actor
• An entity outside the system to be modeled,
  interacting with the system (Pilot)
• Class
• An abstraction modeling an entity in the problem
  domain, inside the system to be modeled
  (Cockpit)
• Object
• A specific instance of a class (Joe, the
  inspector).

5
Associations
TarifSchedule
Enumeration getZones() Price getPrice(Zone)

• Associations denote relationships between
  classes.
• The multiplicity of an association end denotes
  how many objects the source object can
  legitimately reference.

6
1-to-1 and 1-to-Many Associations
1-to-1 association
1-to-many association
7
Aggregation

• An aggregation is a special case of association
  denoting a consists of hierarchy.
• The aggregate is the parent class, the components
  are the children class.

1
0..2
8
Composition

• A solid diamond denote composition, a strong form
  of aggregation where components cannot exist
  without the aggregate.

9
From Problem Statement to Code
Problem Statement
A stock exchange lists many companies. Each
company is identified by a ticker symbol
Class Diagram
lists
Java Code
public class StockExchange public Vector
m_Company new Vector() public class Company
public int m_tickerSymbol public
Vector m_StockExchange new Vector()
10
Generalization

• Generalization relationships denote inheritance
  between classes.
• The children classes inherit the attributes and
  operations of the parent class.
• Generalization simplifies the model by
  eliminating redundancy.

11
UML Sequence Diagrams

• Used during requirements analysis
• To refine use case descriptions
• to find additional objects (participating
  objects)
• Used during system design
• to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
• Lifelines are represented by dashed lines

selectZone()
insertCoins()
pickupChange()
pickUpTicket()
12
UML Sequence Diagrams Nested Messages
ZoneButton
Dataflow
to be continued...

• The source of an arrow indicates the activation
  which sent the message
• An activation is as long as all nested activations

13
Sequence Diagram Observations

• UML sequence diagram represent behavior in terms
  of interactions.
• Complement the class diagrams which represent
  structure.
• Useful to find participating objects.
• Time consuming to build but worth the investment.

14
Activity Diagrams

• An activity diagram shows flow control within a
  system
• An activity diagram is a special case of a state
  chart diagram in which states are activities
  (functions)
• Two types of states
• Action state
• Cannot be decomposed any further
• Happens instantaneously with respect to the
  level of abstraction used in the model
• Activity state
• Can be decomposed further
• The activity is modeled by another activity
  diagram

15
Activity Diagram Modeling Decisions
16
Activity Diagrams Modeling Concurrency

• Synchronization of multiple activities
• Splitting the flow of control into multiple
  threads

Synchronization
Splitting
17
Activity Diagrams Swimlanes

• Actions may be grouped into swimlanes to denote
  the object or subsystem that implements the
  actions.

18
Summary

• UML provides a wide variety of notations for
  representing many aspects of software development
• Powerful, but complex language
• Can be misused to generate unreadable models
• Can be misunderstood when using too many exotic
  features
• We concentrate only on a few notations
• Functional model use case diagram
• Object model class diagram
• Dynamic model sequence diagrams, statechart and
  activity diagrams

19
Chapter 3,Project Communication
20
A Communication Example

• "Two missile electrical boxes manufactured by
  different contractors were joined together by a
  pair of wires.

Box 1
Box 2
Pair of Wires
21
A Communication Example (continued)

• Thanks to a particularly thorough preflight
  check, it was discovered that the wires had been
  reversed."

Box 1
Box 2
22
After the Crash...

• ...
• "The postflight analysis revealed that the
  contractors had indeed corrected the reversed
  wires as instructed."

23

• In fact, both of them had.

Box 1
Box 2
24
Communication is important

• In large system development efforts, you will
  spend more time communicating than coding
• A software engineer needs to learn the so-called
  soft skills technical writing, reading
  documentation, communication, collaboration,
  management, presentations.
• In this course, we ask each of you to (acquire
  and) demonstrate the following skills
• Management Run a team meeting
• Presentation Present a major aspect of
  e-Textbook during its development phase.
• Collaboration Negotiate requirements with the
  client and with members from your team.
• Technical writing Write part of the
  documentation of e-Textbook.

25
Definitions

• Communication mode
• Type of information exchange that has defined
  objectives and scope
• Scheduled Planned Communication
• Event DrivenUnplanned Communication
• Communication mechanism
• Tool or procedure that can be used to transmit
  information
• Synchronous Sender and receiver are available at
  the same time
• Asynchronous Sender and Receiver are not
  communicating at the same time.

26
Classification of Communication
27
Scheduled Communication Modes

• Problem Definition
• Objective Present goals, requirements and
  constraints
• Example Client Presentation
• Usually scheduled at the beginning of a project.
• Project Review Focus on system model
• Objective Assess status and review system model,
  system decomposition, and subsystem interfaces
• Examples Analysis Review, System Design Review
• Scheduled around project milestones and
  deliverables
• Client Review Focus on requirements
• Objective Brief client, agree on requirements
  changes
• Client Review, System Requirements Specification
  (SRS)
• Usually scheduled after analysis phase

28
Scheduled Communication Modes (continued)

• Walkthrough (Informal)
• Objective Increase quality of subsystem
• Example Developer presents subsystem to team
  members, informal, peer-to-peer
• To be scheduled by each team
• Inspection (Formal)
• Objective Compliance with requirements
• Example Client acceptance test (Demonstration
  of final system to customer)
• To be scheduled by project management

29
Scheduled Communication Modes (continued)

• Status Review
• Objective Find deviations from schedule and
  correct them or identify new issues
• Focus on tasks
• Example Status section in regular weekly team
  meeting
• Scheduled every week
• Brainstorming
• Objective Generate and evaluate large number of
  solutions for a problem
• Example Discussion section in regular weekly
  team meeting
• Scheduled every week

30
Scheduled Communication Modes (continued)

• Release
• Objective Baseline the result of each software
  development activity
• Software Project Management Plan (SPMP)
• System Requirements Specification Document (SRS
  (RAD in BD))
• System Design Document (SDD)
• Object Design Document (ODD)
• Test Manual (TM)
• User Manual (UM)
• Usually scheduled after each phase
• Postmortem Review
• Objective Describe Lessons Learned
• Scheduled at the end of the project

31
Event Driven Communication Modes

• Request for clarification
• The bulk of communication among developers,
  clients and users.
• Example A developer may request a clarification
  about an ambiguous sentence in the problem
  statement.
• Request for change
• A participant reports a problem and proposes a
  solution
• Change requests are often formalized when the
  project size is substantial.
• Example A user of a word processing program
  requests that the spelling checker automatically
  corrects certain commonly misspelled words (e.g.
  teh, thes (for this))
• Issue resolution
• Selects a single solution to a problem for which
  several solutions have been proposed.
• Uses issue base to collect problems and proposals

32
Example of Request for Clarification

• From Alice
• Newsgroups cs413.architecture.discuss
• Subject SDD
• Date Thu, 10 Oct 231248 -0400
• Message-ID lt325DBB30.4380_at_andrew.cmu.edugt
• MimeVersion 1.0
• Content-Type text/plain charsetus-ascii
• When exactly would you like the System Design
  Document? There is some confusion over the actual
  deadline the schedule claims it to be October
  22, while the template says we have until
  November 7.
• Thanks,
• Alice

33
Example of a Change Request

• Report number 1291
• Date 5/3
• Author Dave
• Synopsis The e-Textbook client crashes when
  empty forms are submitted.
• Subsystem User interface
• Version 3.4.1
• Classification missing/incorrect functionality,
  convention violation, bug, documentation error
• Severity severe, moderate, annoying
• Description ltltDescription of the problemgtgt
• Rationale ltltWhy the change should be donegtgt
• Proposed solution ltltDescription of desired
  changegtgt

34
Synchronous Communication Mechanisms

• Smoke signals
• Supports ?, Pros ?, Cons ?
• Hallway conversation (face-to-face)
• Supports Unplanned conversations, Request for
  clarification, request for change
• Pro Cheap and effective for resolving simple
  problems
• Con Important information can be lost,
  misunderstandings can occur when conversation is
  relayed to others.
• Meeting (face-to-face, telephone, video
  conference)
• Supports Planned conversations, client review,
  project review, status review, brainstorming,
  issue resolution
• Pro Effective mechanism for resolution of
  isssues, and building consensus
• Con High cost (people, resources) difficulty of
  managing them and getting effective results

35
Meeting Roles

• Primary facilitator
• Responsible for organizing the meeting and
  guiding the execution.
• Writes the agenda describing objective and scope
  of meeting.
• Distribute the agenda to the meeting participants
• Minute taker
• Responsible for recording the meeting.
• Identifies action items and issues
• Release them to the participants
• Time keeper
• Responsible for keeping track of time

36
Structure of a Meeting Agenda
37
Asynchronous Communication Mechanisms

• E-Mail
• Supports Release, change request, brainstorming
• Pro Ideal for event-driven communication modes
  and announcements.
• Con E-mail taken out of context can be easily
  misunderstood, sent to the wrong person, lost or
  not read by the receiver.
• Newsgroups
• Supports Release, change request, brainstorming
• Pro Suited for notification and discussion among
  people who share a common interest cheap
  (shareware available)
• Con Primitive access control (often, you are
  either in or out)
• World Wide Web
• Supports Release, change request, inspections
• Pro Provide the user with a hypertext metaphor
  Documents contain links to other documents.
• Con Does not easily support rapidly evolving
  documents

38
Asynchronous Communication Mechanisms

• Lotus Notes
• Each user sees the information space as a set of
  databases, containing documents composed of a set
  of fields. Users collaborate by crating, sharing
  and modifying documents
• Supports Release, change request, brainstorming
• Pro Provides excellent access control mechanisms
  and replication of databases.
• Con Proprietary format, expensive

39
Fill out the Review Form

• Select reviewers
• Select the document to be reviewed
• Add comments to reviewers
• Determine deadline

40
Reviewer Notification

• Selected reviewers get e-mail

41
Reviewers add their Comments
42
Originator Notification
43
Final Recipient Notification
44
Review Tasks

• Editor reviews comments
• Editor selects reviewed comments
• Web Master posts reviewed document and action
  items
• Team members complete their action items
• Editor integrates changes
• Editor posts changed document on the review
  database for the next review cycle

45
Summary

• Communication Modes
• Scheduled communication
• Event-driven communication
• Communication Mechanisms
• Asynchronous communication mechanisms
• Synchronous communication mechanisms
• Important modes and mechanisms
• Weekly meeting
• Project reviews
• Online communication (discussion forum, email,
  web)