UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit,...

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit , Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1

Class Diagrams

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.

Enumeration getZones()Price getPrice(Zone)

TariffSchedule

* *

Tripzone:Zoneprice:Price


Classes

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.

zone2pricegetZones()getPrice()

TariffSchedule

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule


Instances

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.

zone2price = {{‘1’, .20},{‘2’, .40},{‘3’, .60}}

tariff_1974:TarifSchedule


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”).


Associations

Associations denote relationships between classes. The multiplicity of an association end denotes how many

objects the source object can legitimately reference.

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* pricezone

TripLeg

*


1-to-1 and 1-to-Many Associations

1-to-1 association

1-to-many association

*

draw()

Polygon

x:Integery:Integer

Point1

Has-capital

name:String

Country

name:String

City11


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

Exhaust System

Muffler Tailpipe

0..2


Composition

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

3

TicketMachine

ZoneButton


From Problem Statement to Code

Problem StatementA stock exchange lists many companies. Each company is identified by a ticker symbol

Class Diagram

Java Codepublic class StockExchange { public Vector m_Company = new Vector();};public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector();};

*StockExchange

tickerSymbol

Company*lists


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.

Button

ZoneButtonCancelButton


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()

pickupChange()

pickUpTicket()

insertCoins()

PassengerTicketMachine


UML Sequence Diagrams: Nested Messages

The source of an arrow indicates the activation which sent the message

An activation is as long as all nested activations

selectZone()

PassengerZoneButton TarifSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow

…to be continued...


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.


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

HandleIncident

DocumentIncident

ArchiveIncident


Activity Diagram: Modeling Decisions

OpenIncident

NotifyPolice Chief

NotifyFire Chief

AllocateResources

[fire & highPriority]

[not fire & highPriority]

[lowPriority]


Activity Diagrams: Modeling Concurrency

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

SynchronizationSplitting

ArchiveIncident

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources


Activity Diagrams: Swimlanes

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

ArchiveIncident

Dispatcher

FieldOfficer

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources


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

Con

quer

ing

Com

plex

and

Cha

ngin

g S

yste

ms

Ob

ject

-Ori

ente

d S

oftw

are

En

gin

eeri

ng Chapter 3,

Project Communication


Pair of WiresBox 1 Box 2

A Communication Example

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


Box 1 Box 2

A Communication Example (continued)

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


After the Crash...

...

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


“In fact, both of them had.”

Box 1 Box 2


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.


Definitions

Communication mode Type of information exchange that has defined objectives and

scope Scheduled: Planned Communication Event Driven:Unplanned 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.


Classification of Communication

is supported by

* *

SynchronousMechanism

AsynchronousMechanism

CommunicationMechanism

Event-drivenMode

ScheduledMode

CommunicationMode


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


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



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



Release Objective: Baseline the result of each software development activity Software Project Management Plan (SPMP) System Requirements Specification Document (SRS (RAD in

B&D)) 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


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


Example of Request for Clarification

From: Alice

Newsgroups: cs413.architecture.discuss

Subject: SDD

Date: Thu, 10 Oct 23:12:48 -0400

Message-ID: <[email protected]>

MimeVersion: 1.0

Content-Type: text/plain; charset=us-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


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: <<Description of the problem>>

Rationale: <<Why the change should be done>>

Proposed solution: <<Description of desired change>>


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


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


Structure of a Meeting Agenda


Asynchronous Communication MechanismsE-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


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


Fill out the Review Form

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


Reviewer Notification

Selected reviewers get e-mail


Reviewers add their Comments


Originator Notification


Final Recipient Notification


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


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)

UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit,...

Documents

Transcript of UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit,...