Software Engineering I (02161) Week 5 Assoc. Prof. Hubert - - PowerPoint PPT Presentation

▶
software engineering i 02161
SMART_READER_LITE
LIVE PREVIEW

Software Engineering I (02161) Week 5 Assoc. Prof. Hubert - - PowerPoint PPT Presentation

Feb 07, 2024 136 likes •617 views

Software Engineering I (02161) Week 5 Assoc. Prof. Hubert Baumeister Informatics and Mathematical Modelling Technical University of Denmark Spring 2011 2011 H. Baumeister (IMM) c Software Engineering I (02161) Spring 2011 5 / 65 Recap

slide-1
SLIDE 1

Software Engineering I (02161)

Week 5

  • Assoc. Prof. Hubert Baumeister

Informatics and Mathematical Modelling Technical University of Denmark

Spring 2011

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 5 / 65

slide-2
SLIDE 2

Recap

Recap: Class Diagrams

Class diagram: Visualize OO programs (i.e. based on OO programming languages)

→ However, have more abstract language

Classes: combines data and methods related to a common aspect (e.g. Person, Address, Company, . . . ) Generalization between classes (corresponds to inheritance) Association between classes

Unidirectonal

Associations vs. attributes

Multiplicities and how to implement them: 0..1, 1, * Bi-directional Qualifed assocations: Corresponds to the use of maps or dictionaries Aggregation and Composition

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 7 / 65

slide-3
SLIDE 3

Activity Diagrams

Activity Diagram: Business Processes

Describe the context of the system Helps finding the requirements of a system

modelling business processes leads to suggestions for possible systems and ways how to interact with them Software systems need to fit in into existing business processes

Ian Sommerville, Software Engineering – 9, 2010

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 9 / 65

slide-4
SLIDE 4

Activity Diagrams

Activity Diagram Example Workflow

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 10 / 65

slide-5
SLIDE 5

Activity Diagrams

Activity Diagram Example Operation

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 11 / 65

slide-6
SLIDE 6

Activity Diagrams

UML Activity Diagrams

Focus is on control flow and data flow Good for showing parallel/concurrent control flow Purpose

Model business processes Model workflows Model single operations

Literature: UML Distilled by Martin Fowler

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 12 / 65

slide-7
SLIDE 7

Activity Diagrams

Activity Diagram Concepts

Actions

Are atomic E.g Sending a message, doing some computation, raising an exception, . . .

UML has approx. 45 Action types

Concurrency

Fork: Creates concurrent flows

Can be true concurrency Can be interleaving

Join: Synchronisation of concurrent activities

Wait for all concurrent activities to finish (based on token semantics)

Decisions

Notation: Diamond with conditions on outgoing transitions else denotes the transition to take if no other condition is satisfied

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 13 / 65

slide-8
SLIDE 8

Activity Diagrams

Activity Diagrams Execution

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 14 / 65

slide-9
SLIDE 9

Activity Diagrams

Swimlanes / Partitions

Swimlanes show who is performing an activity

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 15 / 65

slide-10
SLIDE 10

Activity Diagrams

Objectflow example

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 16 / 65

slide-11
SLIDE 11

Activity Diagrams

Data flow and Control flow

Data flow and control flow are shown:

Order Make Payment Receive Invoice

Control flow can be omitted if implied by the data flow:

Order Make Payment Receive Invoice

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 17 / 65

slide-12
SLIDE 12

Activity Diagrams

Use of Activity Diagrams

Emphasise on concurrent/parallel execution Requirements phase

To model business processes / workflows to be automated

Design phase

Show the semantics of one operation

Close to a graphic programming language

An activity diagram only shows one perspective of the dynamic aspect of the system

Use several activity diagrams and don’t put everything into one diagram

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 18 / 65

slide-13
SLIDE 13

From Requirements to Design: CRC Cards

Activities in Software Developement

Understand and document what kind of the software the customer wants

→ Requirements Analysis

Determine how the software is to be built

→ Design

Build the software

→ Implementation

Validate that the software solves the customers problem

→ Testing → Verification → Evaluation: e.g. User friendlieness

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 20 / 65

slide-14
SLIDE 14

From Requirements to Design: CRC Cards

From Requirements to Design: Solution

Design process 1 The terms in the glossary give first candidates for classes, attributes, and operations 2 Take one use cases

a Take one main or alternative scneario

i Realize that scenario by adding new classes, attributes, associations, and operations so that you design can execute that scenario (ii implement the design) (in case of an agile software development process)

b Repeat step a with the other scenarios of the use case

3 Repeat step 2 with the other use cases Techniques that can be used

Grammatical analysis of the text of the scenario

→ nouns are candidate for classes and attributes; verbs are candidates for operations, and adjectives are candidates for attributes

CRC cards (= Class Responsibility Collaboration cards)

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 21 / 65

slide-15
SLIDE 15

From Requirements to Design: CRC Cards

Introduction CRC Cards

CRC cards were developed by Ward Cunningham in the late 80’s Can be used for different purposes

Analyse a problem domain Discover object-oriented designs

Learn to think objects

→ Objects

have structure and behaviour → both need to be considered at the same time

Literature

http://c2.com/doc/oopsla89/paper.html Martin Fowler: UML Destilled pages 62—63

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 22 / 65

slide-16
SLIDE 16

From Requirements to Design: CRC Cards

CRC Card

Class

Can be an object of a certain type Can be the class of an object Can be a component of a system Index cards are used to represent classes (one for each class) (I use A6 paper instead of index cards)

Responsibilities

Corresponds roughly to operations and attributes Somewhat larger in scope than operations ”do something” ”know something”

Collaborations

With whom needs this class to collaborate to realize its responsibilities

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 23 / 65

slide-17
SLIDE 17

From Requirements to Design: CRC Cards

CRC Card Template

A larger example http://c2.com/doc/crc/draw.html

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 24 / 65

slide-18
SLIDE 18

From Requirements to Design: CRC Cards

Process I

Starting point

List of use-cases scenarios

Should be as concrete as possible

A group of up to 2–6 people

Brainstorming

Initial set of Classes (just enough to get started) Assign Classes to persons

Execute Scenarios

Simulate how the computer would execute the scenario Each object/class is represented by one person This person is responsible for executing a given responsibility

This is done by calling the responsibilities of other objects/persons he collaborates with

  • bjects/classes can be created

responsibilitites can be added collaborations can be added

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 25 / 65

slide-19
SLIDE 19

From Requirements to Design: CRC Cards

Library Example: Detailed Use Case Check Out Book

Name: Check Out Book Description: The user checks out a book from the library Actor: User Main scenario:

1 A user presents a book for check-out at the check-out counter 2 The system registers the loan

Alternative scenarios:

The user already has 10 books borrowed

2a The system denies the loan

The user has one overdue book

2b The system denies the loan

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 26 / 65

slide-20
SLIDE 20

From Requirements to Design: CRC Cards

Example II

Set of initial CRC cards

Librarien

The object in the system that fulfills User requests to check out, check in, and search for library materials

Borrower

The set of objects that represent Users who borrow items from the library

Book

The set of objects that represent items to be borrowed from the library

Use case Check out book main scenario

”What happens when Barbara Stewart, who has no accrued fines and

  • ne outstanding book, not overdue, checks out a book entitled

Effective C++ Strategies+?”

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 27 / 65

slide-21
SLIDE 21

From Requirements to Design: CRC Cards

Library Example: All CRC cards

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 29 / 65

slide-22
SLIDE 22

From Requirements to Design: CRC Cards

Process: Next Steps

Review the result

Group cards

by collaborations shows relationship between classes

Check responsibilities Check correct representation of the domain Refactor if needed

Transfer the result

UML class diagrams

Responsibilities map to operations and attributes/associations Collaborations map to associations and dependencies

The executed scenarios to UML interaction diagrams

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 30 / 65

slide-23
SLIDE 23

From Requirements to Design: CRC Cards

Example: Class Diagram (so far)

0..1 * Borrower canBorrow Book isOverdue checkOut(b:Borrower) calculateDueDate Librarien checkOutBook(b:Book) Date compare(d:Date) * * 0..1 dueDate

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 31 / 65

slide-24
SLIDE 24

From Requirements to Design: CRC Cards

Example: Sequence Diagram for Check-out book

Check Out Book Realization c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 32 / 65

slide-25
SLIDE 25

From Requirements to Design: CRC Cards

Summary

Further scenarios give more detail The scenarios are now quite easy to implement CRC process can be repeated on a more detailed level, e.g., to design the database interaction, or user interface Helps one to think in objects (structure and behaviour) Humans playing objects help to get a better object-oriented design as it helps delegating responsibilities

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 33 / 65

slide-26
SLIDE 26

Sequence Diagrams

Interaction Diagrams

Purpose

Describes how objects collaborate in some behaviour

Types

Sequence Diagrams

1990’s: Message Sequence Charts (MSCs) used in TelCo-industry

Communication Diagrams Timing Diagrams

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 35 / 65

slide-27
SLIDE 27

Sequence Diagrams

Example Sequence Diagrams

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 36 / 65

slide-28
SLIDE 28

Sequence Diagrams

Example Communication Diagrams

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 37 / 65

slide-29
SLIDE 29

Sequence Diagrams

Use of Sequence Diagrams

Usually a single scenario

But can be extended to include several interactions → Executable UML / UML as a programming language

Class/object interactions

Express message exchange between objects Design message exchange Get an overview of existing systems

Use Case Scenarios

Illustrate a concrete scenario of a use case Useful for design/documentation (Analysis, design, and reengineering)

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 38 / 65

slide-30
SLIDE 30

Sequence Diagrams

Sequence Diagram Concepts

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 39 / 65

slide-31
SLIDE 31

Sequence Diagrams

Creation and deletion of participants

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 40 / 65

slide-32
SLIDE 32

Sequence Diagrams

Arrow types

a:A b:B async call sync call return

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 41 / 65

slide-33
SLIDE 33

Sequence Diagrams

Interaction Frames Example

Realising an algorithm using a sequence diagram public void dispatch() { for (LineItem lineItem : lineItems) { if (lineItem.getValue() > 10000) { careful.dispatch(); } else { regular.dispatch(); } } if (needsConfirmation()) { messenger.confirm(); } }

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 42 / 65

slide-34
SLIDE 34

Sequence Diagrams

Realisation with Interaction Frames

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 43 / 65

slide-35
SLIDE 35

Sequence Diagrams

Interaction Frame Operators I

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 44 / 65

slide-36
SLIDE 36

Sequence Diagrams

When to use sequence diagrams

Useful to visualize complex interactions between objects

Visualize the control flow in an object-oriented system Reverse Engineering but also Forward Engineering

Useful to describe Use Case scenarios Sequence diagrams are less useful for describing algorithms

→ Use state machines to show the behaviour of a single object across several scenarios → Use activity diagrams to show the behaviour of across many

  • bjects and threads

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 45 / 65

slide-37
SLIDE 37

Object-orientation: Centralized vs Decentralized Control/Computation

Computing the price of an order

Task

Calculate the price of an order Take into account if the customer has any discounts

Order calculate price calculate base price calculate discounts Product name price Customer name discount info OrderLine quantity * 1 1

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 47 / 65

slide-38
SLIDE 38

Object-orientation: Centralized vs Decentralized Control/Computation

Computation is concentrated in one class (centralised control)

The order computes the price by asking its collaborators about data → centralised control

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 48 / 65

slide-39
SLIDE 39

Object-orientation: Centralized vs Decentralized Control/Computation

Centralised Control: Class diagram

Order calculate price calculate base price calculate discounts Product name price Customer name discount info OrderLine quantity * 1 1

Only class Order has any interesting behaviour OrderLine, Customer, and Product are purely data classes (no methods)

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 49 / 65

slide-40
SLIDE 40

Object-orientation: Centralized vs Decentralized Control/Computation

Computation is distributed among several objects (distributed control)

The order computes the price by delegating part of the price calculation to order line and customer → distributed control

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 50 / 65

slide-41
SLIDE 41

Object-orientation: Centralized vs Decentralized Control/Computation

Distributed Control: Class diagram

Order calculate price calculate base price calculate discounts Product name price get price for quantity Customer name discount info calculate discount OrderLine quantity calculate price * 1 1

More customer types can be added Each computing the discount differently The product now calculates the price depending on quantity One could now have products that are cheaper the more one buys

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 51 / 65

slide-42
SLIDE 42

Object-orientation: Centralized vs Decentralized Control/Computation

Design for change (I): Centralized Control

centralized control B C A m 0 m1(B) m2(C) m3(D) D

public class A { private B b; private D d; public void m0() { m1(b); C c = getC(); m2(c); m3(d); } public void m1() {...} public void m2() {...} public void m3() {...} } Question: How easily can m0 be adapted?

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 52 / 65

slide-43
SLIDE 43

Object-orientation: Centralized vs Decentralized Control/Computation

Design for change (II): Distributed Control

distributed control A m 0 B m1(A) m2(A) D m3(A) C m2(B)

public class A { private B b; private D d; public void m0() { b.m1(this); b.m2(this); d.m3(this); } } public class B { private C c; public void m2(A a) { c.m2(this); } }

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 53 / 65

slide-44
SLIDE 44

Object-orientation: Centralized vs Decentralized Control/Computation

Design for change (III): Distributed Control

distributed control A m 0 B m1(A) m2(A) D m3(A) C m2(B) B1 m1(A) m2(A) D1 m3(A)

The behaviour of m0 can be adapted by using new subclasses of A, B, C, and D The subclasses have each their

  • wn version of m0, m1, m2, and

m3 What happens if a new subclass, e.g. D2, is added? New subclasses can be easily added to adapt the behaviour, without m0 having to change → The system can be used and adapted to situations which one has not thought of in the beginning

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 54 / 65

slide-45
SLIDE 45

Object-orientation: Centralized vs Decentralized Control/Computation

Design for change (IV): Centralized Control

m0 has to deal itself with all possible subclasses → use of instanceof What happens if a new subclass, e.g. D2 is added to the system? → m0 has to change

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 55 / 65

slide-46
SLIDE 46

Object-orientation: Centralized vs Decentralized Control/Computation

Centralised vs Distributed Control

Centralised control

One method does all the work The remaining objects are merely data objects and usually don’t have their own behaviour Typical for a procedural programming style

Distributed control

Objects collaborate to achieve one task Each object in a collaboration has behaviour (= is a ”real” object) Typical object-oriented style

Each object has its own responsibilities Creates adaptable designs

Object-Orientation Distributed Control is a characteristic of object orientation

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 56 / 65

slide-47
SLIDE 47

Summary

Summary

Activity Diagrams From requirements to design: CRC cards Sequence Diagrams Object Orientation: Centralized vs Decentralized control

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 58 / 65

slide-48
SLIDE 48

Summary

Software Engineering I (02161)

Week 5

  • Assoc. Prof. Hubert Baumeister

Informatics and Mathematical Modelling Technical University of Denmark

Spring 2011

c 2011 H. Baumeister (IMM) Software Engineering I (02161) Spring 2011 64 / 65