Homework Due Next Week

• Use Case Diagram, Class Diagram, User Interface, State Diagram

Design Phases

continued

Where Are We?

• We’ve done our Product Design resulting in – Use Cases/Use Case diagrams– Class diagrams (initial)– State diagrams– Deployment diagram

Where Are We? (cont.)

• We’ve also produced– Object Persistence specifications– Process Architecture– Human-Computer Interface specifications

• What’s next?– Class Design (internals)

Relationships of SE Phases and UML Diagrams

Analysis Use Cases Scenarios Class Diagrams

Class DesignObject Diagrams

InteractionDiagrams

Class Diagrams

Class Skeletons

ImplementationClass

Definitions

Relationships of SE Phases and UML Diagrams

Analysis Use Cases Scenarios Class Diagrams

Class DesignObject Diagrams

InteractionDiagrams

Class Diagrams

Class Skeletons

ImplementationClass

Definitions

System Decomposition

• Convert general/abstract models created during the analysis phase into detailed models

• Stepwise refinement/evolutionary development

• Leads directly to the system implementation

Class Design

• Expand on the analysis deliverables to ensure complete functionality coverage– We’re about to commit ourselves so we want to

make sure the design is complete and correct• Add detail to class diagrams

– Attributes– Method signatures

Produce a class skeleton which will eventually turn into code

Class Diagrams Revisited• Portray the elements of a class and the

relationships between classes– Class– Interface– Relationship– Collaborations

Class Diagrams (cont.)

• Class– May be just a class name– May include attributes

and/or access methods

class-name

class-name

attribute1attribute2

method1()

method2(int)

method3()

Class Diagrams (cont.)

• Relationships (between classes)– Association

– Generalization

– Dependency

class-1 class-2does-something-to

base-class derived-class

change-me change-me too

Class Diagrams (cont.)

• Interface– Class interactions– Enforces

encapsulation– Generally left out

until the design phase

class-1 class-2

interface-1

Class Diagrams (cont.)

• Collaboration– Specifies that

multiple elements must interact to produce a given behavior

class-1 class-2interface-1

class-3

update-operation

Class Diagrams (cont.)

• Access modifiers– Specify the mode of

access of class methods and attributes

• Public• Private• Protected

class-name

-privateatt0-privateatt1

+public0()

-private0(int)

#protected0()

Class Diagrams (cont.)

• Multiplicity– Cardinality of an

association relationship

Patron Resouce0..1 0..*

Class Diagrams (cont.)

• Role– Descriptive label

about the part an object plays in the association Patron Resouce0..1 0..*

Borrower

Class Diagrams (cont.)

• Constraints• Tagged values

– Special circumstances that must be considered

– Versioning of diagrams

– Associations with functional requirements

– Nonstandard information

Patron Resource0..1 0..*Borrower

{Requirement #5}{Student at most 25 resources}{Faculty and staff – no limit}

Class Diagrams (cont.)

• Aggregation– Class containment– Filled diamond means

the contained class cannot exist on its own

– Hollow diamond means the contained class can exist on its own

Address

Patron

Patron

OverdueNotice

Resource

Name

Aggregation

• Often represented as an association

• Often represented by inclusion of an object type (class) in the attribute field of the including class

• All techniques are acceptable– Just make sure your designs are clear and

concise

Interaction Diagrams

• Specify the interactions between classes– This information is absent in the Class

Diagrams (only show relationships)– Collaboration Diagrams

• Structure of interactions

– Sequence Diagrams• Time ordering of interactions (messages)

Interaction Diagrams (cont.)• Consists of

– Objects• Instance of a class (not the class itself)

• Links/Messages– Association between instances– Corresponds to an association in the Class

Diagram– Likely to be implemented as a method

(function) call

Interaction Diagrams (cont.)• Loosely speaking

Use CaseScenarioinstance of

Class DiagramInteraction Diagraminstance of

– Analysis phase

– Design phase

– You’ll have one for each scenario

Interaction Diagrams (cont.)

Object-name : class

method-name(params)

Object Link

Message

• Symbols

Collaboration Diagram

• Also known as a Communication diagram (UML 2.0)

• Describe the Structure of interactions between classes

Collaboration Diagram

:Life

:Grid :User Interface

CreateGrid(rows, columns) GetSizes(rows, columns)

:Cell

CreateCell()

DrawGrid()

EnterSize(rows)EnterSize(columns)

User

Initiate Game Scenario{Requirement #2}

Collaboration Diagram (cont.)

:Grid :User Interface

:Cell

SetColor(bool occ)

DrawGrid()

UpdateCell(row, col)

Set Cells Scenario

User

LBCallback(row, col)

Collaboration Diagram (cont.)

:Grid :User Interface

:Cell

UpdateCell()

:Ruleset

UpdateCell(row, col)

DrawGrid()

Run Rules Scenario

User

StartCallback()

ApplyRules()

:Timer

Start()

Collaboration Diagram (cont.)• Just another step in the evolution of

the system– Class Diagrams outline the general

associations– Scenarios provide detailed “stories”– Combining the two provides us with clues

to needed classes/methods/attributes/interfaces

Collaboration Diagram (cont.)• Development of collaboration diagrams

is an art, not a science– Basically, you’re writing programs, you’re

just doing it pictorially and at a level a step or two above actual “programming”

• It all starts with the Use Cases and Scenarios and proceeds by adding detail to the Class Diagrams

Sequence Diagram

• Describe the timing or ordering of interactions (messages) between classes

Sequence Diagram

:Life :User Interface

GetSizes(rows, columns)

:Grid

CreateGrid(rows, columns)

:Cell

CreateCell()

DrawGrid()

Initiate Game Scenario{Requirement #2}

{Continue only when therows/columns are less than 100}

Sequence Diagram (cont.)• Similar content to Collaboration Diagrams• Add the notion of “time”

– Time increases from top to bottom– Topmost objects/messages are created/sent

first– Objects may come and go over the life of the

system

• Again, it’s an art, not a science

Object Diagram

• Yet another look at the system

• Encompasses a snapshot of the running system

• Contains object instances and their relationships rather than classes

• Indirectly related to (or analogous to) Informal Scenarios

Object Diagram

:Life:Gridrows = 12Cols = 16

:Cell(0,0)occupied

:Cell(0,1)occupied

:Cell(11,15)unoccupied

Why All The Diagrams?

• Code reuse– Identify reusable classes (inheritance/aggregate)

• Well-designed classes and methods– Private attributes (data)– Proper initialization (constructor)– Abstract data types (aggregates)– Self-documenting (attribute/method names)

• Assurance of data integrity– Object updates (interrelated transactions)

Why All The Diagrams? (cont.)• IT’S EASIER TO CHANGE THESE

DIAGRAMS THAN IT IS TO CHANGE CODE!

• IT’S EASIER TO DEBUG WELL WRITTEN CODE THAN POORLY WRITTEN CODE!

Code

• But what is “well written code”?

What About This Code?main(t,_,a )char*a;{return!

0<t?t<3?

main(-79,-13,a+main(-87,1-_,main(-86, 0, a+1 )

+a)):

1,t<_?main( t+1, _, a ):3,

main ( -94, -27+t, a )&&t == 2 ?_<13 ?

main ( 2, _+1, "%s %d %d\n" )

:9:16:t<0?t<-72?

main( _, t,"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l,+,/n{n+,/+#n+,\/#;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l q#'+d'K#!/+k#;q#'r}eKK#}\w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# ){nl]!/n{n#'; r{#w'r nc{nl]'\/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'\}{nlwb!/*de}'c ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'\{n' ')# }'+}##(!!/"):t<-50?_==*a ?putchar(31[a]):

main(-65,_,a+1):main((*a == '/') + t, _, a + 1 ):

0<t?

main ( 2, 2 , "%s"):*a=='/'||

main(0,

main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry")

,a+1);}

Code

Diagrams to Code

• Code can be written in many, many different styles for many, many different goals

• The diagrams are nice and useful but they’re not code

• How can we convert them to code while retaining their documentary nature?

• We need an intermediate step• Class skeletons

Class Skeleton

• Consists of these sections– List of roles– Information maintenance– Attributes – Constructors– Methods

• Can be written in the target language or a psuedo-language

Roles

• Behavior of the class within a context

• In a particular situation, what does the class provide?– May partition the class into functionalities

that can be designed independently

Information Maintenance• Specifies when objects of a particular

class type are created and deleted– Not all classes/instances will be used

throughout the entire execution of the system

Attributes

• Instance variables – Hold data specific to an instance of the

class

• Class variables – Hold data common to all instances of the

class– Also called static class variables

Constructors/Destructors• Called when a class is instantiated

– Allocation of memory for the instance– Initialization of instance variables– Modification of class variables

• Called when a class instance is removed from the system– Deallocate instance memory– Modification of class variables

Methods

• Non-static member functions– Modify/operate on instance variables of the

class

• Static member functions– Modify/operate on the class variables of

the class

Skeleton

public class Patron{

// Class semantics and roles:// Library patrons function in two primary roles,// as researchers who use index, reference, and database// materials and as borrowers of loanable resources

// Information maintenance:// Creation: New patrons are introduced into the system// by library staff when presented with a library// membership application or from information retrieved// from a web-based application form.// Deletion: Patrons are removed from the library database// 3 years after their membership has expired

Skeleton (cont.)

// Instance variables:private String name; // name of Patron in

// <last-name, first-name, MI> orderprivate long PatronID; // Patron’s library identification

// number sequentially generatedprivate long homephone; // Patron’s home phone number in

// 11 digits (xxx)yyy-zzzz stored as// xxxyyyzzzz

private Date memberDate; // date of first membership in// mmddyyyy format

private Date expireDate; //date membership expires in// mmddyyyy format

private List resourceList; // Object reference to Patron’s// list of checked out resources

private Address homeAddress; // Object reference to// patron’s home address

Skeleton (cont.)

// Class variables:private static long nextPatronID; // keeps track of the

// next patron membership ID to// be assigned

// Constructors:public Patron(String name, long homePhone, Date memberDate,

Date expireDate, String street, String city, String state, long zip)

{ // TODO List:// PatronID = getnextPatronID()// Create an Address object initialized with street,// city, state, and zip// Create Date objects for membership data and// expiration dates initialized with memberDate and// expireDate.

Skeleton (cont.)

// Precondition: Library database can accept another// entry and memory allocation succeeds// Postcondition: Library database will contain another// Patron and Address entry

}

// Destructors: (C++ -- finalize() in Java)~Patron(){ // Precondition: Patron object is not null // deallocate any memory allocated by the constructor

// or other nonstatic methods}

// Static methods:public static long getnextPatronID(){ return nextPatronID; nextPatronID++;}

Skeleton (cont.)

// Nonstatic methods:public boolean validatePatron(Date expire){ // precondition: expireDate is not null

expire = expireDate; // pass expiration date back to // calling function via parameter // list

// if expireDate <= Today return false// else return true

}

public boolean checkout(Resource resourceID){ // precondition: resourceID points to a legitimate // Resource object that is available for checkout // postcondition: if resource list is null, one is // created, otherwise a new Resource reference is added // to the patron’s List of checked out resources}

}

Skeleton (cont.)

• This class skeleton is written in what looks like (is) Java/C++

• It need not be

• A pseudo-language can be used so long as the pertinent information is conveyed

Where Does This Get Us?• We’ve started the process of writing

code– At least something that directly

corresponds to code– May not be done by the actual

programmers

• We’ve started the process of documenting the code