homework due next week
DESCRIPTION
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.). - PowerPoint PPT PresentationTRANSCRIPT
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