class design another look part 1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Class Design Another Look – Part 1 PowerPoint Presentation
Download Presentation
Class Design Another Look – Part 1

Loading in 2 Seconds...

play fullscreen
1 / 44

Class Design Another Look – Part 1 - PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on

Class Design Another Look – Part 1. Note: there is so much more than below…. More facts regarding Class Design Re-look at Persistent Classes Re-look at Class Operations Scope of Operations Methods States – State Charts Attributes Defining Dependencies and Associations

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Class Design Another Look – Part 1


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
note there is so much more than below
Note: there is so much more than below…
  • More facts regarding Class DesignRe-look at Persistent ClassesRe-look at Class Operations
  • Scope of OperationsMethodsStates – State ChartsAttributes
  • Defining Dependenciesand Associations
  • GeneralizationsMultiple InheritancePolymorphism
we want to
We want to:
  • Refine relationships, operations, and attributes
  • Focus on fleshing out the details of a particular class – operations needed and allocated to classes and how they collaborate to support the responsibilities allocated to the class.
  • Address non- functional requirements
  • We will look at Design patterns in the very near future.
slide4

Class Design in Context*

Architectural

Analysis

Review the

Architecture

Describe

Architectural

Describe

Architecture

Reviewer

Architect

Concurrency

Design

Distribution

Subsystem Design

Use-Case

Analysis

Review the

Use-Case

Design

Design

Design

Designer

Reviewer

Class

Design

This is where we stand. Recall:

Architectural Design is where we decide what the infrastructure is (pieces and parts of the architecture and how they interact).

Use Case Designis where theresponsibilities of the system are allocated to the pieces/parts; Subsystem and Class design are where we detail the specifics of the pieces/parts.

class design in context
Class Design in Context*

Architectural

Analysis

Review the

Architecture

Describe

Architectural

Describe

Architecture

Reviewer

Architect

Concurrency

Design

Distribution

Subsystem Design

Use-Case

Analysis

Review the

Use-Case

Design

Design

Design

Designer

Reviewer

Class Design

  • During Class Design, we consider: implementation and deployment environments.
  • May need to adjust the classes to the particular products in use, the programming languages,
  • distribution, performance, use of component architectures like COM or CORBA, and other
  • constraints
  • Frequent iteration between Class Design, Subsystem Design and Use Case Design.
  • Class Design - performed for each class in current iteration.
slide6

How Many Classes Are Needed?

  •  Many, simple classes means that each class
    • Encapsulates less of the overall system intelligence
    • Is more reusable
    • Is easier to implement
  •  Few, complex classes means that each class
    • Encapsulates a large portion of the overall system intelligence
    • Is less likely to be reusable
    • Is more difficult to implement
  • Proper size may depend heavily on implementation environment – classes should map directly to some phenomenon in the implementation language in such a way that the mapping results in good code.

A class should have a single well focused purpose.

A class should do one thing and do it well!

slide7

DropDownList

MainWindow

SubWindow

Button

MainForm

Recall: Boundary Classes – External System Interface:*

  • Note:
    • Usually model as subsystem (recall Billing System interface?)
    • Oftentimes these interfaces have complex internal behavior (hence the modeling as a subsystem)
recall entity classes 1 of 3
Recall: Entity Classes (1 of 3)
  • Entity objects are often passive and persistent
  • In Analysis, we identified entity classes.
    • May have been associated with analysis mechanisms for persistence representing manipulated units of information.
    • Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model. (Re-factoring covered ahead)
      • Maybe only ‘parts’ of objects need persistency….
entity classes sample of re factoring

<< entity >>

FatClass

FatClass

-transientBookeeping

- transientBookeeping

+ commonlyUsedAtt1

+ getCommonlyUsedAtt1()

+ commonlyUsedAtt2

+ getCommonlyUsedAtt2()

+ rarelyUsedAtt3

+ getRarelyUsedAtt3()

+ rarelyUsedAtt4

+ getRarelyUsedAtt4()

FatClassDataHelper

FatClassLazyDataHelper

+ commonlyUsedAtt1

+ rarelyUsedAtt3

+ commonlyUsedAtt2

+ rarelyUsedAtt4

Entity Classes - Sample of Re-factoring
  • Have persistent class with five attributes.
  • One attribute is not really persistent – used during runtime
  • Use Cases tell us two attributes used a lot; two others less.
  • In design, we would like to retrieve commonly used attributes right away but defer others until asked for.
    • But we don’t want a complex design for the client.
    • So:

Analysis

Design

1

1

entity classes

<< entity >>

FatClass

FatClass

-transientBookeeping

- transientBookeeping

+ commonlyUsedAtt1

+ getCommonlyUsedAtt1()

+ commonlyUsedAtt2

+ getCommonlyUsedAtt2()

+ rarelyUsedAtt3

+ getRarelyUsedAtt3()

+ rarelyUsedAtt4

+ getRarelyUsedAtt4()

FatClassDataHelper

FatClassLazyDataHelper

+ rarelyUsedAtt3

+ commonlyUsedAtt1

+ rarelyUsedAtt4

+ commonlyUsedAtt2

Entity Classes
  • From a data standpoint, will consider the FatClass to be a proxy in front of the two real persistent data classes.
  • It will retrieve FatClassDataHelper from database when it is first retrieved. Will retrieve FatClassLazyDataHelper in rare occasion when a client asks for one of these attributes.
  • This is a view from a data-oriented perspective while retaining a logical object-oriented view for clients to use.
  • It is tuning for performance too.

Analysis

Design

So, which would you rather

retrieve?? FatClass or

FatClassDataHelper?

1

1

slide11

Recall: Control Classes

  • What Happens to Control Classes?
    • Are they really needed? Split them?
    • If they seem like just ‘pass throughs’ from the boundary to the entity classes, eliminate them.
  • Control Classes may become true design classes for any of following reasons:
    • Encapsulate significant control flow behavior
    • High probability of Change
    • Behaviors are to be distributed across multiple processes and/or processors (often JSP, servlets…)
    • The behavior they encapsulate requires some transaction management
  • A single analysis control class can easily become two classes in design
class design steps identify persistent classes
Class Design Steps – Identify Persistent Classes
  • In Use-Case Analysis,
    • a vague notion that certain classes need to be persistent
    • But this is just the 'tip of the iceberg' of system design.
  • Now, in Class Design, get really specific about
    • what the classes are, (are there more?)
    • what their behaviors are (parameters, et al), and
    • what attributes these classes really have.
  • Now, we must be certain
    • which classes will have persistent instances, and
    • that all persistent classes should be mapped to a storage mechanism.
slide13

Course

Student

Client

Class

Analysis

Mechanism

(Conceptual)

Design

Mechanism

(Concrete)

Implementation

Mechanism

(Actual)

Legacy Data

Persistency

RDBMS

JDBC to Ingres

New Data

ObjectStore

OODBMS

Persistency

  • Persistent class? Any instance of the class that requires its state to be preserved.
    • A persistent class may have both persistent and transient instances
    • labeling a class 'persistent' means merely that some instances of the class may need to be persistent.
important note
Important Note.
  • Persistent classes may not only come from entity classes.
  • Could also be other classes required to handle other non-functional requirements in general.
  • Examples:
    • Persistent objects needed to maintain information relevant to process control, or
    • Persistent objects needed to maintain state information between transactions.
re look at class operations
Re-look at Class Operations
  • Purpose
    • Map responsibilities (analysis) to operations (design) that implement them
  • Things to consider :
    • Operation name, signature, and description
    • Operation visibility
    • Operation scope
      • Class operation vs. instance operation
  • Operations: define at most primitive level to promote reusability and maintainability.
operations name and describe
Operations: Name and Describe
  • Appropriate operation names

Indicate the outcome – e.g. getBalance().

Consistent across classes

  • Define operation signatures
    • operationName(parameter : class,..) : returnType
    • Best to specify operations and their parameters using implementation language syntax and semantics.
    • Thus the interfaces will already be specified in terms of the implementation language when coding starts.
  •  Always provide short textual description, including meaning of all parameters for an operation!!!
operation signatures guidelines
Operation Signatures: Guidelines
  • In addition to a short description of the parameter, be sure to include:
    • Parameters passed by-value or by-reference?
      • If by value, parameter cannot be changed.
      • If by reference, is parameter(s) changed?
    • Parameters optional?
    • Default parameter values?
    • Valid parameter ranges?
  • The fewer the parameters, the better.
    •  less coupling; more understandable and maintainable.
  •  Pass objects instead of “data bits” – a rich strength of OO.
discovering additional classes and relationships

Class2

Class3

Discovering Additional Classes and Relationships

ClassA

op1(var1:Class2): Class3

  • Parameters and return types may lead to discovery
  • of other classes.
  • Operation parameters and return classes denote
  • a relationship between these classes and the
  • parameter class and/or the return class.
  • In many cases, the relationships added to
  • support operation signatures are dependency
  • relationships.
  • Dependency relationships are discussed ahead.
  • This applies to attributes as well as operations..

What does the class

diagram above tell

you???

Additional classes and relationships may be added to support signature

slide19

Class

- privateAttribute

# protectedAttribute

+publicOp()

# protectedOp()

- privateOp()

How Is Visibility Noted?

  • The following symbols are used to specify export control for attributes and operations:
    • + Public access
    • # Protected access
    • - Private access
    • In Java we also have package visibility. Symbol??
scope of operation and attributes

Class

- classifierScopeAttribute

- instanceScopeAttribute

classifierScopeOperation()

instanceScopeOperation()

Scope of Operation and Attributes
  • Determines number of instances of the attribute or operation.
    • Instance scope: one instance for each class instance
    • Class scope: one instance for all class instances
  • Class scope: underline attribute/operation name
    • Cannot do this in Rose, but can use stereotype <<class>> to indicate class scope
    • Generally, we have instance scope; but can have class scope for may other practical reasons: counters, etc.
    • Class scoped operations can only access class-scoped attributes.
example scope

<<entity>>

Student

- name

- address

- studentID

- nextAvailID : int

+ addSchedule(theSchedule : Schedule, forSemester : Semester)

+ getSchedule(forSemester : Semester) : Schedule

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

# passed(theCourseOffering : CourseOffering) : boolean

+ getNextAvailID() : int

Example: Scope
  • Here, have a single classifier scoped attribute, nextAvailID; single classifier
  • scoped operation, getNextAvailID().
  • These support the generation of a unique ID for each Student.
  • Each Student instance has it’s own unique Student-ID, whereas, there is only
  • one nextAvailID for all Student instances.
  • The getNextAvailID() classifier scoped operation can only access nextAvailID.
utility classes

<<utility>>

MathFunctions

Utility Classes
  • What is a Utility Class?
    • Utility is a class stereotype
    • Used for a class that contains a collection of free subprograms
      • Free subprograms are nonmember functions, that is, functions that do not belong to a particular class.
  • Why use it?
    • To provide services that may be (re)useful in a variety of contexts (e.g. common algorithmic services)
    • Or, to wrap non object-oriented libraries or applications
  • In Use
    • No ‘instances’ of a utility class; all attributes / ops are considered classifier scoped (class scope).
    • Utility classes are not formal UML constructs, but can be defined for programming convenience. (Will see more ahead)
example utility classes

<<utility>>

MathPack

-randomSeed : long = 0

-pi : double = 3.14159265358979

+sin (angle : double) : double

+cos (angle : double) : double

+random() : double

Example: Utility Classes*

Discuss syntax

of class…

Note: all properties and methods are class-scoped.

example portion of vopc for the register for courses use case realization
Example: Portion of VOPC for the Register for Courses Use Case Realization

<<Interface>>

<<control>>

ICourseCatalogSystem

RegistrationController

1

(from External System Interfaces)

0..*

(from Registration)

+ getCourseOfferings()

+ submitSchedule()

+ initialize()

+ saveSchedule()

+ getCourseOfferings() : CourseOfferingList

+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule

+ deleteCurrentSchedule()

+currentSchedule

<<class>> + new(forStudent : string)

0..1

<<entity>>

+ getStudent(withID : string) : Student

Schedule

0..1

(from University Artifacts)

0..1

0..*

0..*

0..*

+registrant

0..1

<<entity>>

+alternateCourses

1

Student.

+primaryCourses

(from University Artifacts)

0..4

+ getTuition() : double

0..2

+ addSchedule(theSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

<<entity>>

+ deleteSchedule(forSemester : Semester)

CourseOffering

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

(from University Artifacts)

# passed(theCourseOffering : CourseOffering) : boolean

Note: the <<class>> operations.

Note: + classes (invoked by clients);

# - only invoked by defining class/subclasses,

(usually correspond to reflexive operations

on interaction diagrams; (more )

<<class>> + getNextAvailID() : int

+ getStudentID() : int

+ getName() : string

+ getAddress() : string

example portion of vopc for the register for courses use case realization1
Example: Portion of VOPC for the Register for Courses Use Case Realization*

<<Interface>>

<<control>>

ICourseCatalogSystem

RegistrationController

1

(from External System Interfaces)

0..*

(from Registration)

+ getCourseOfferings()

+ submitSchedule()

+ initialize()

+ saveSchedule()

+ getCourseOfferings() : CourseOfferingList

+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule

+ deleteCurrentSchedule()

+currentSchedule

<<class>> + new(forStudent : string)

0..1

<<entity>>

+ getStudent(withID : string) : Student

Schedule

0..1

(from University Artifacts)

0..1

0..*

0..*

0..*

+registrant

0..1

<<entity>>

+alternateCourses

1

Student.

+primaryCourses

(from University Artifacts)

0..4

+ getTuition() : double

0..2

+ addSchedule(theSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

<<entity>>

+ deleteSchedule(forSemester : Semester)

CourseOffering

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

(from University Artifacts)

# passed(theCourseOffering : CourseOffering) : boolean

Dependency from Student to CourseOfferingClass

was added to support the inclusion of the

CourseOffering as a parameter to operations

within the Student Class.

Do you understand what this means??

<<class>> + getNextAvailID() : int

+ getStudentID() : int

+ getName() : string

+ getAddress() : string

example portion of vopc for the register for courses
Example: Portion of VOPC for the Register for Courses

(Attribute compartments supressed here)

<<Interface>>

<<control>>

ICourseCatalogSystem

RegistrationController

1

(from External System Interfaces)

0..*

(from Registration)

+ getCourseOfferings()

+ submitSchedule()

+ initialize()

+ saveSchedule()

+ getCourseOfferings() : CourseOfferingList

+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule

+ deleteCurrentSchedule()

+currentSchedule

<<class>> + new(forStudent : string)

0..1

<<entity>>

+ getStudent(withID : string) : Student

Schedule

0..1

(from University Artifacts)

0..1

0..*

0..*

0..*

+registrant

0..1

<<entity>>

+alternateCourses

1

Student.

+primaryCourses

(from University Artifacts)

0..4

+ getTuition() : double

0..2

+ addSchedule(theSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

<<entity>>

+ deleteSchedule(forSemester : Semester)

CourseOffering

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

(from University Artifacts)

# passed(theCourseOffering : CourseOffering) : boolean

Semester is included as the type for several

parameters in Student ops. For Course Registration

System, it is considered to be an abstract data

type that has no significant behavior and thus is

not modeled as a separate class.

<<class>> + getNextAvailID() : int

+ getStudentID() : int

+ getName() : string

+ getAddress() : string

?

review package element visibility

A

PackageB

PackageA

B

Class A1

+Class B1

Class A3

Class A2

-Class B2

Review: Package Element Visibility

Only public classes can be referenced outside of the owning package

Can specify visibility for package elements in same way as class attributes / operations (can protect classes)

Shows how other packages can access the elements owned by the package.

(Have visibility symbols for packages)

Class has Public visibility

Class has Private visibility

OO Principle: Encapsulation

review package element visibility1

A

PackageB

PackageA

B

Class A1

+Class B1

Class A3

Class A2

-Class B2

Review: Package Element Visibility

Public classes can

be accessed

outside of owning

package.

Protected classes

only be accessed

by owning package &

any packages that

inherit from owning

package.

Private classes can

only be accessed

by classes within

owning package.

Public elements of

package constitute

package’s interface.

Class has Public visibility

Class has Private visibility

OO Principle: Encapsulation

define dependency

Client

Supplier

Define Dependency
  • What Is a Dependency?
    • A relationship between two objects
    • In analysis, we assumed relationships were ‘structural’

that is, associations or aggregations- parts, numbers, coincident lifetimes, one – to – many, etc.

    • In design, we must decide what type of communication pathway is required.
    • A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client.
    • Need to
      • Determine where structural relationships are NOT required
      • What causes the supplier to be visible to the client
dependencies vs associations

Supplier1

Supplier2

Client

Dependencies vs. Associations*
  • Read these carefully:
  • Associations are structural relationships
  • Dependencies are non-structural relationships

Dependency

Association

communication pathways to suppliers
Communication pathways to suppliers***
  • Four communications pathways to supplier…
    • Local variable reference – supplier object is declared locally (created temporarily during execution of an operation)
    • Parameter reference – supplier object is a parameter to, or the return class of, an operation in the client object.
    • Global reference – supplier object is global.
    • Field reference – The supplier object is a data member in the client object.
dependencies vs associations look at relationships what are they going to be become

Supplier1

Supplier2

Client

Dependencies vs. Associations: Look at relationships: What are they going to be/become?
  • Associations and aggregations are structuralrelationships (field visibility).
    • We’re talking about ‘Association relationships’ realized by variables that exist in the data member section of the class definition.
  • Dependency is a type of communication pathway that is a more temporary type of relationship –global, parameter, local visibility
    •  Any relationships not associations are dependency

Association

Dependency

local variable visibility dependency

ClassA

op1 ()

ClassB

Local Variable Visibility  Dependency
  • The op1() operation contains a local variable of type ClassB. Hence there is a dependency between these two classes.
parameter visibility dependency

ClassA

op1 (param1: ClassB)

ClassB

Parameter Visibility  Dependency
  • The ClassB instance is passed to the ClassA instance – hence a dependency.
global visibility dependency

ClassA

op1 ()

ClassUtility

utilityOp ()

Global Visibility  Dependency
  • The ClassUtility instance is visible because it is global. Clear dependency.
identifying dependencies considerations
Identifying Dependencies: Considerations
  • Strive for real-world relationships
  • Strive for the lightest relationships possible (dependency)
    • Dependency is the cheapest to keep, easiest to utilize and benefit from encapsulation.
  •  Sometimes a relationship may be more permanent (aggregation) and sometimes the same kind of relationship might be a dependency.
identifying dependencies considerations1
Identifying Dependencies: Considerations
  • Is relationship “permanent”? Use association (field visibility)
    • Will I need this relationship again and again over time, or do I just need it to do some work and then I throw it away?
    • If I need it again and again, i.e., if a thing appears to remain related to another thing even across the execution of one or more operations, then it is likely as association and therefore should benefit from field visibility.
identifying dependencies considerations2
Identifying Dependencies: Considerations
  • Is relationship “temporary”? Use dependency
    • Multiple objects at run time share the same instance again and again, probably should be passing it as a parameter…(parameter visibility)
    • Or if there is only one in existence in whole process, set it up as a managed global (Singleton design pattern – next week)
    • If same instance is not shared, then a local copy should suffice; i.e., multiple objects don’t share the same instance – use local visibility.
identifying dependencies considerations3
Identifying Dependencies: Considerations
  •  No exact recipe for decision
  • How long does it take to create/destroy?
  • Expensive to connect/disconnect every time I need it?
    • If so, use field, parameter (association), or global visibility (dependency).
  •  All variations of dependencies are dependent on situations.
  •  Choice? Design it however it works best in your circumstances…
example define dependencies before vopc register for courses use case

<<Interface>>

ICourseCatalogSystem

(from External System Interfaces)

+ getCourseOfferings(forSemester : Semester) : CourseOfferingList

1

courseCatalog

0..*

<<entity>>

<<control>>

Schedule

RegistrationController

(from University Artifacts)

(from Registration)

- semester

currentSchedule

+ // submit schedule()

+ submit()

0..1

0..1

+ // save schedule()

+ // save()

+ // create schedule with offerings()

# any conflicts?()

+ // getCourseOfferings(forSemester) : CourseOfferingList

+ // create with offerings()

0..*

0..1

0..*

0..*

alternateCourses

primaryCourses

1

registrant

0..2

0..4

0..1

<<entity>>

<<entity>>

CourseOffering

Student

(from University Artifacts)

(from University Artifacts)

- number : String = "100"

- name

- startTime : Time

- address

- endTime : Time

- StudentID : int

- days : Enum

+ addSchedule(theSchedule : Schedule, forSemester : Semester)

+ addStudent(studentSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

+ removeStudent(studentSchedule : Schedule)

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

+ new()

# passed(theCourseOffering : CourseOffering) : boolean

+ setData()

Example:Define Dependencies (before) VOPC Register for Courses Use Case

Up to here, most relationships have been

associations and aggregations. Now, will

see how some of these are refined

into dependencies.

The dependency

shown (next slide)

was previously

defined in the Define

Ops section to support

the Schedule

operation signatures.

All associations

/aggregations

should be

examined to

see if they are

dependencies.

example define dependencies after

<<Interface>>

ICourseCatalogSystem

(from External System Interfaces)

+ getCourseOfferings(forSemester : Semester) : CourseOfferingList

Global visibility

<<entity>>

<<control>>

Schedule

RegistrationController

(from University Artifacts)

(from Registration)

- semester

currentSchedule

+ // submit schedule()

+ submit()

0..1

0..1

+ // save schedule()

+ // save()

+ // create schedule with offerings()

Field visibility

# any conflicts?()

+ // getCourseOfferings(forSemester) : CourseOfferingList

+ // create with offerings()

0..*

0..1

0..*

0..*

Field visibility

alternateCourses

primaryCourses

1

registrant

0..2

0..4

0..1

<<entity>>

<<entity>>

CourseOffering

Student

(from University Artifacts)

(from University Artifacts)

- number : String = "100"

- name

- startTime : Time

- address

- endTime : Time

- StudentID : int

- days : Enum

+ addSchedule(theSchedule : Schedule, forSemester : Semester)

+ addStudent(studentSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

+ removeStudent(studentSchedule : Schedule)

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

+ new()

# passed(theCourseOffering : CourseOffering) : boolean

+ setData()

Parameter visibility

Example: Define Dependencies (after)

Changed one association to a dependency relationship. (This change discussed on ‘next’ slide)

Here, during a registration session, the Registration Controller works with a singleStudent, the registrant,

and oneSchedule, the current Schedule for the Student.

These instances need to be accessed by

more than one of the Registration Controller’s,

operations so Field Visibility is chosen

from Registration Controller

to Student and from

Registration Controller

to Schedule.

Thus relationships

remain

associations.

(more ‘permanent’)

A Student

manages its

own Schedules,

so Field visibility

is chosen from

Student to

Schedule –

and relation

remains

aggregation.

Again, more

‘permanent.’

More 

example define dependencies after1

<<Interface>>

ICourseCatalogSystem

(from External System Interfaces)

+ getCourseOfferings(forSemester : Semester) : CourseOfferingList

Global visibility

<<entity>>

<<control>>

Schedule

RegistrationController

(from University Artifacts)

(from Registration)

- semester

currentSchedule

+ // submit schedule()

+ submit()

0..1

0..1

+ // save schedule()

+ // save()

+ // create schedule with offerings()

Field visibility

# any conflicts?()

+ // getCourseOfferings(forSemester) : CourseOfferingList

+ // create with offerings()

0..*

0..1

0..*

0..*

Field visibility

alternateCourses

primaryCourses

1

registrant

0..2

0..4

0..1

<<entity>>

<<entity>>

CourseOffering

Student

(from University Artifacts)

(from University Artifacts)

- number : String = "100"

- name

- startTime : Time

- address

- endTime : Time

- StudentID : int

- days : Enum

+ addSchedule(theSchedule : Schedule, forSemester : Semester)

+ addStudent(studentSchedule : Schedule)

+ getSchedule(forSemester : Semester) : Schedule

+ removeStudent(studentSchedule : Schedule)

+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean

+ new()

# passed(theCourseOffering : CourseOffering) : boolean

+ setData()

Parameter visibility

Example: Define Dependencies (after)

Course Offerings are part of semantics of what defines a Schedule (courses Student has

selected). Thus Field visibility is chosen from Schedule to CourseOffering; relationships remain associations.

The Student class has several operations

where CourseOffering appears in the

parameter list. Thus, Parameter visibility

is chosen from Student to

CourseOffering.

It is envisioned

the course Catalog

System may need

to be accessed by

multiple clients

in the system, so

Global visibility

was chosen –

and relationship

becomes a

dependency.