Object Oriented Analysis and Design-Introduction to Software Engineering-Lecture 10 Slides-Computer Science, Slides of Introduction to Software Engineering

Download Object Oriented Analysis and Design-Introduction to Software Engineering-Lecture 10 Slides-Computer Science and more Slides Introduction to Software Engineering in PDF only on Docsity!

ECE 452- Introduction to Software

Engineering

Lecture 11: Object-Oriented

Analysis & Design

Manish Parashar [email protected] Department of Electrical & Computer Engineering Rutgers University ECE 452 - Introduction to Software Engineering

System Sequence Diagrams

aDetermine system events and operations aDerived from UseCases – Typical course of events aSystem boundary is critical aIdentify system functionality (operations) to be designed

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams still in

analysis

aIllustrate events from actors to systems aSystem sequence diagrams describe scenarios a scenario is an instance of a use case _Ivar Jacobson_a real example of the enactment of a use case `like Play One Round done in section aSome UML notation for a sequence diagram is shown on the next slide

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams

aDraw a line repesenting the system as a black box. aIdentify each actor that directly operates on the system. Draw a line for each such actor. aFrom expanded use case identify system events that each actor generates. Ilustrate them. aOptionally include use case text on left.

ECE 452 - Introduction to Software Engineering

A System Sequence Diagram

enterItem(UPC, quantity)

Cashier :System

endSale()

Repeat until nomore items

makePayment(amount) Text which clarifiescontrol, logic, iteration, etc. May be taken from theuse case.

Actor Buy Items-version 1

system as black box

system event it triggers a system operation ECE 452 - Introduction to Software Engineering

System events

aSystem Event: An external input event generated by an actor to a system the system is seen as a black box aSystem operationthe method invoked in response to a system event aUse the same names for system event and system operation aSystem events may have arguments ⌧enterItem( UPC, quantity ) ⌧raise( money )

ECE 452 - Introduction to Software Engineering

Drawing System Sequence Diagrams

aWe drew ours differently in Section than Craig aBut both have a column for the actor and the system aBoth have a notion of a system boundary aBoth provide a nice way to show interaction between actors and the system aDifferent: We used arrows to indicate system responsesOurs was on the whiteboard and was erased ECE 452 - Introduction to Software Engineering

System Behavior - Contracts

aContracts help define system behavior aContracts are defined in part by preconditions and postconditions aExamples in this chapter document system operations such as enterItemendSale `makePayment aHowever, contracts also apply to low-level methods

ECE 452 - Introduction to Software Engineering

Contracts

aContract: A document that describes what an operation promises to achieve Emphasizes what will happen, not how aSee enterItem contract on page 148We won't be doing a contract document `But here are some possible contracts ⌧startNewGame system event pre: player range 1.. ⌧raise low level method

• pre: money is in range 0..maxbet, post: pot and player holding changed ⌧humanChooses low-level method
• pre: player know state of round, post: returns one of the few selections

ECE 452 - Introduction to Software Engineering

From Analysis to Design

aAnalysis phase of development emphasizes an understanding of the requirements, concepts, and operations related to a system. Focused on what rather than how aSome analysis artifactsUses Cases, Conceptual Model, System Sequence Diagrams, Contracts

ECE 452 - Introduction to Software Engineering

From Analysis to Design

aUse Cases What are the domain processes? aConceptual ModelWhat are the concepts, terms? aSystem sequence diagrams What are the system events and operations? aContractsWhat do the system operations do?

ECE 452 - Introduction to Software Engineering

Design Phase Initiation

aArtifacts to be created during Design Interaction Diagrams ⌧How objects communicate to accomplish a taskDesign Class Diagram ⌧Show class definitions (instance variables and methods) aUpcoming chapters explore creation of these two artifacts Interaction diagrams require creativityNeed to assign responsibilities and apply design patterns

ECE 452 - Introduction to Software Engineering

Describing Real Use Cases

aReal use case: Describes the real or actual design of the use case in terms of concrete input and output One of the first design phase activities within a development cycleCould be diagrams of a GUI ⌧A sketch of a desired view for example aA real use case needs an essential use case aYou may skip these and nail it down during implementation see picture of GUI on page 165

ECE 452 - Introduction to Software Engineering

Collaboration Diagrams

aQuestion: How are objects going to do what we believe the system should be doing? Answer: In a variety of ways _such as 'Design by Coding'_ aIn the next two chapters, UML notation is shown for capturing how objects accomplish their task. Examples with POST are given aComing up:Chapter 17 shows UML notation `Chapter 18 gives design guidelines

ECE 452 - Introduction to Software Engineering

Activities

aInteraction diagrams indicate how objects interact via messages aAt this point we need (and we have) a conceptual model from which to get objectsto know what the system must do use cases to glean information from aThere are two kinds of interaction diagramsCollaboration Diagrams illustrate objects in a graph format `Sequence diagrams show messages on a time line

ECE 452 - Introduction to Software Engineering

Example

aSequence Diagram

makeCreditPayment(ccNum, expiryDate) requestApproval(request) handleCreditReply(reply)

Customer (^) ReceivableAccounts AuthorizationServiceCredit

addApproval(reply)

:System

ECE 452 - Introduction to Software Engineering

Example

aCollaboration Diagram

:Sale 1: create() sl: SalesLineItem

2: add(sl) :SalesLineItemSalesLineItem

msg1()

ECE 452 - Introduction to Software Engineering

Collaboration Diagrams

aLarman reports that collaboration diagrams are better than sequence diagrams exceptional expressivenessconvey contextual information where we are `can say more in a given space aIllustrates how objects interact via messages aThe next slide shows UML notation

ECE 452 - Introduction to Software Engineering

Example Collaboration Diagram

1: makePayment(cashTendered) 1.1: create(cashTendered)

:POST :Sale

:Payment

makePayment(cashTendered)

argument

direction of message

first message instance

first internal message

link line

1. makePayment message sent to a POST object this is a system message initiated by an actor
2. POST object sends makePayment message to Sale object
3. Sale constructs a Payment ECE 452 - Introduction to Software Engineering

Making Collaboration Diagrams

aTo make a collaboration diagram Create a separate diagram for each system operation ⌧ **POST** makePayment ⌧ **Poker** raise aUse cases are one source of inputSuch as the few you have aWe'll use design patterns and guidelines to design a system of interacting objects that fulfill tasks

ECE 452 - Introduction to Software Engineering

Back to UML Notations: Notation Only Chapter

aIllustrating Classes and Instances

Sale :Sale s1: Sale

class instance named instance

Player :Player p1: Player

class instance named instance ECE 452 - Introduction to Software Engineering

Illustrating Links

aA Link is a connection between two instances `Indicates navigation and visibility ⌧Example: show two instances in client server relationship

:POST 1: addPayment(cashTendered) :Sale

msg1()

link line

:BettingRoundManager 1: whatShouldYouDo(): Integer :Player

doBettingRound()

ECE 452 - Introduction to Software Engineering

Illustrate messages with arguments, return type

aUML syntax for message return := message(parameter: parameterType):returnType

:PokerGame 1: addPlayer(aPlayer: Player): Boolean :PlayerList

addPlayer()

standard UMLmessage syntax

ECE 452 - Introduction to Software Engineering

Illustrating this

aAn object can send a message to itself `Here is the UML notation

:POST

msg1()

1: clear()

ECE 452 - Introduction to Software Engineering

Illustrating Creation

aUse create not new

:POST 1: create(cashier) :Sale

msg1()

create message, withoptional initializing parameters

new created instance

«new»:Sale "«new»" is optionallyallowed for emphasis

Create a sale using an instance of cashier

ECE 452 - Introduction to Software Engineering

Illustrating Iteration

aIteration indicated by *

:POST 1*: [i := 1..10] li := nextLineItem(): SalesLineItem :Sale

msg1()

iteration clause

ECE 452 - Introduction to Software Engineering

Illustrating Selection

aSquare brackets indicate a conditional `The message is sent only if new sale is true

:POST 1: [new sale] create() :Sale

:SalesLineItem

1.1: create()

msg1()

conditional message, with test

ECE 452 - Introduction to Software Engineering

GRASP - Patterns for Assigning

responsibilities

aAn object-oriented system is composed of objects sending messages to other objects to complete operations aOne question is: "Who is responsible for what" aOne answer is: "Do CRC card development with role play (or interaction diagrams) while using Design heuristics _like Rick's and Arthur Riel's_Larman's responsibility assignment patterns pattlets `Design Patterns like from the Gang of Four book

ECE 452 - Introduction to Software Engineering

Assigning Responsibilities

aResponsibilities: What an object should be able to ⌧do something itself ⌧delegate responsibility (send messages) to other objects ⌧control and coordinate activities in other objectsWhat an object should know ⌧private state ⌧knowing about related objects

ECE 452 - Introduction to Software Engineering

Assigning responsibilities

aWhere we are today CRC card development (or collaboration diagrams) is an important artifactSkillful assignment of responsibilities is important Should spend a lot of time assigning responsibilitiesPatterns and guidelines can be applied to improve the quality of your design

ECE 452 - Introduction to Software Engineering

Patterns

aPattern: A named description of a problem and a solution that can be applied in many contexts aExample Context: You are trying to determine who should be responsible for deciding whether a bet is appropriate (or if a library customer can borrow) Solution: Assign the responsibility to the class that has the information to fulfill it Larman's Name for this pattern: Expert