Class Diagrams Tariff Schedule Enumeration get Zones Price

Class Diagrams Tariff. Schedule Enumeration get. Zones() Price get. Price(Zone) ¨ ¨ * * Trip zone: Zone price: Price Class diagrams represent the structure of the system. Class diagrams are used w during requirements analysis to model problem domain concepts w during system design to model subsystems and interfaces w during object design to model classes. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1

Classes Name Tariff. Schedule zone 2 price get. Zones() get. Price() ¨ ¨ ¨ Attributes Operations Tariff. Schedule Table zone 2 price Enumeration get. Zones() Price get. Price(Zone) Signature Tariff. Schedule 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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

Instances tariff_1974: Tarif. Schedule zone 2 price = { {‘ 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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3

Actor vs. Instances ¨ ¨ What is the difference between an actor and a class and an instance? Actor: w An entity outside the system to be modeled, interacting with the system (“Pilot”) ¨ Class: w An abstraction modeling an entity in the problem domain, inside the system to be modeled (“Cockpit”) ¨ Object: w A specific instance of a class (“Joe, the inspector”). UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4

Associations Tarif. Schedule Enumeration get. Zones() Price get. Price(Zone) ¨ ¨ Trip. Leg * * price zone Associations denote relationships between classes. The multiplicity of an association end denotes how many objects the source object can legitimately reference. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5

1 -to-1 and 1 -to-Many Associations Country name: String Has-capital 1 1 City name: String 1 -to-1 association Polygon 1 * Point x: Integer y: Integer draw() 1 -to-many association UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6

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. Exhaust System 1 Muffler 0. . 2 Tailpipe UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7

Composition ¨ A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. Ticket. Machine 3 Zone. Button UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8

From Problem Statement to Code Problem Statement A stock exchange lists many companies. Each company is identified by a ticker symbol Class Diagram Stock. Exchange lists * * Company ticker. Symbol Java Code public class Stock. Exchange { public Vector m_Company = new Vector(); }; public class Company { public int m_ticker. Symbol; public Vector m_Stock. Exchange = new Vector(); }; UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9

Generalization Button Cancel. Button ¨ ¨ ¨ Zone. Button 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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10

UML Sequence Diagrams ¨ Passenger Used during requirements analysis w To refine use case descriptions w to find additional objects (“participating objects”) Ticket. Machine select. Zone() ¨ Used during system design w to refine subsystem interfaces insert. Coins() ¨ ¨ pickup. Change() pick. Up. Ticket() ¨ ¨ Classes are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11

UML Sequence Diagrams: Nested Messages Passenger Zone. Button select. Zone() Tarif. Schedule Display lookup. Price(selection) price Dataflow display. Price(price) …to be continued. . . ¨ ¨ The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12

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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13

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: ¨ w Action state: t t Cannot be decomposed any further Happens “instantaneously” with respect to the level of abstraction used in the model w Activity state: t t Can be decomposed further The activity is modeled by another activity diagram UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14

Activity Diagram: Modeling Decisions UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15

Activity Diagrams: Modeling Concurrency ¨ ¨ Synchronization of multiple activities Splitting the flow of control into multiple threads Splitting Synchronization Allocate Resources Open Incident Coordinate Resources Archive Incident Document Incident UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16

Activity Diagrams: Swimlanes ¨ Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. Allocate Resources Open Incident Coordinate Resources Document Incident Dispatcher Archive Incident Field. Officer UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17

Summary ¨ UML provides a wide variety of notations for representing many aspects of software development w Powerful, but complex language w Can be misused to generate unreadable models w Can be misunderstood when using too many exotic features ¨ We concentrate only on a few notations: w Functional model: use case diagram w Object model: class diagram w Dynamic model: sequence diagrams, statechart and activity diagrams UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18

Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 3, Project Communication

A Communication Example "Two missile electrical boxes manufactured by different contractors were joined together by a pair of wires. Box 1 Pair of Wires Box 2 UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20

A Communication Example (continued) Thanks to a particularly thorough preflight check, it was discovered that the wires had been reversed. " Box 1 Box 2 UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21

After the Crash. . . "The postflight analysis revealed that the contractors had indeed corrected the reversed wires as instructed. " UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22

“In fact, both of them had. ” Box 1 Box 2 UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23

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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24

Definitions Communication mode ¨ Type of information exchange that has defined objectives and scope ¨ Scheduled: Planned Communication ¨ Event Driven: Unplanned 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. UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25

Classification of Communication Mode Scheduled Mode is supported by * Event-driven Mode Communication Mechanism * Synchronous Mechanism Asynchronous Mechanism UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26

Scheduled Communication Modes Problem Definition w Objective: Present goals, requirements and constraints w Example: Client Presentation w Usually scheduled at the beginning of a project. Project Review: Focus on system model w Objective: Assess status and review system model, system decomposition, and subsystem interfaces w Examples: Analysis Review, System Design Review w Scheduled around project milestones and deliverables Client Review: Focus on requirements w Objective: Brief client, agree on requirements changes w Client Review, System Requirements Specification (SRS) w Usually scheduled after analysis phase UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27

Scheduled Communication Modes (continued) Walkthrough (Informal) w Objective: Increase quality of subsystem w Example: Developer presents subsystem to team members, informal, peer-to-peer w To be scheduled by each team Inspection (Formal) w Objective: Compliance with requirements w Example: Client acceptance test (Demonstration of final system to customer) w To be scheduled by project management UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28

Scheduled Communication Modes (continued) Status Review w Objective: Find deviations from schedule and correct them or identify new issues w Focus on tasks w Example: Status section in regular weekly team meeting w Scheduled every week Brainstorming w Objective: Generate and evaluate large number of solutions for a problem w Example: Discussion section in regular weekly team meeting w Scheduled every week UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29

Scheduled Communication Modes (continued) Release w w w w 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 w Objective: Describe Lessons Learned w Scheduled at the end of the project UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30

Event Driven Communication Modes Request for clarification w The bulk of communication among developers, clients and users. w Example: A developer may request a clarification about an ambiguous sentence in the problem statement. Request for change w A participant reports a problem and proposes a solution w Change requests are often formalized when the project size is substantial. w 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 w Selects a single solution to a problem for which several solutions have been proposed. w Uses issue base to collect problems and proposals UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31

Example of Request for Clarification From: Alice Newsgroups: cs 413. architecture. discuss Subject: SDD Date: Thu, 10 Oct 23: 12: 48 -0400 Message-ID: <325 DBB 30. 4380@andrew. cmu. edu> Mime. Version: 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 UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32

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>> UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33

Synchronous Communication Mechanisms Smoke signals w Supports: ? , Pros: ? , Cons: ? Hallway conversation (face-to-face) w Supports: Unplanned conversations, Request for clarification, request for change w Pro: Cheap and effective for resolving simple problems w Con: Important information can be lost, misunderstandings can occur when conversation is relayed to others. Meeting (face-to-face, telephone, video conference) w Supports: Planned conversations, client review, project review, status review, brainstorming, issue resolution w Pro: Effective mechanism for resolution of isssues, and building consensus w Con: High cost (people, resources); difficulty of managing them and getting effective results UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34

Meeting Roles ¨ Primary facilitator w Responsible for organizing the meeting and guiding the execution. w Writes the agenda describing objective and scope of meeting. w Distribute the agenda to the meeting participants ¨ Minute taker w Responsible for recording the meeting. w Identifies action items and issues w Release them to the participants ¨ Time keeper w Responsible for keeping track of time UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35

Structure of a Meeting Agenda UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36

Asynchronous Communication Mechanisms E-Mail w Supports: Release, change request, brainstorming w Pro: Ideal for event-driven communication modes and announcements. w Con: E-mail taken out of context can be easily misunderstood, sent to the wrong person, lost or not read by the receiver. Newsgroups w Supports: Release, change request, brainstorming w Pro: Suited for notification and discussion among people who share a common interest; cheap (shareware available) w Con: Primitive access control (often, you are either in or out) World Wide Web w Supports: Release, change request, inspections w Pro: Provide the user with a hypertext metaphor: Documents contain links to other documents. w Con: Does not easily support rapidly evolving documents UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37

Asynchronous Communication Mechanisms Lotus Notes w 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 w Supports: Release, change request, brainstorming w Pro: Provides excellent access control mechanisms and replication of databases. w Con: Proprietary format, expensive UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38

Fill out the Review Form ¨ ¨ Select reviewers Select the document to be reviewed Add comments to reviewers Determine deadline UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39

Reviewer Notification ¨ Selected reviewers get e-mail UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40

Reviewers add their Comments UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41

Originator Notification UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42

Final Recipient Notification UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43

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 UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44

Summary ¨ Communication Modes w Scheduled communication w Event-driven communication ¨ Communication Mechanisms w Asynchronous communication mechanisms w Synchronous communication mechanisms ¨ Important modes and mechanisms w Weekly meeting w Project reviews w Online communication (discussion forum, email, web) UNB CS 3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45