Unformatted text preview:

I/O of Designing a ClassDesign a ClassOutlining Design ClassDesigning Control ClassIdentifying OperationsExample: Invoice ClassIdentifying AttributesDescribing StatesSummary: Design ModelSummary: Deployment ModelI/O of Designing a ClassDesign a Class•Its operations•Attributes•Relationship it participates in•Methods (that realize the operations)•Its imposed states•Its dependency to any generic design mechanisms•Requirements relevant to its implementation•Correct realization of any interface it is required to provideOutlining Design Class•Goal is to decide on a strategy, from class interface to implementation•Use stereotype of analysis class to determine method to be used–Boundary class depends on specific interface technology–Entity class on specific DB technology, e.g. map to tables in relational DB.–Control class - more delicate, see next slideDesigning Control Class•Distribution issue. If sequence of operations need to be distributed/managed by several nodes in a network, separate design class on each node may be needed to realize the control class. E.g. traffic control•Performance issue. It may not be justifiable to have separate design class to realize the control class•Transaction issue. Corresponding design class must incorporate existing transaction management technology•Remember: traceability to analysis modelIdentifying Operations•Responsibilities of any analysis class that the design class traces to•Special requirements of corresponding analysis class. Q. example?•Operations of associated interfaces•Use case realization in which the class participates (need to support all the roles that the class playsExample: Invoice Class•Used in use-cases: –Pay Invoice: schedule invoice–Send Reminder–Invoice Buyer: create & submit invoice–Each read or change class stateIdentifying Attributes•Attributes from analysis class•Available attribute types restricted or provided by programming language•When choosing a type, try to reuse existing one•Split class if attributes become to complexDescribing States•For objects whose behavior is determined by its states, it’s meaningful to describe important state transitions•Example: state change follows strict sequenceSummary: Design Model•Subsystem and their dependencies, interfaces and contents•Design classes, including active classes, and their operations, attributes, relationships, and implementation requirements•Use case realization, describing how use cases are designed via collaboration within the design model•Architectural view of designSummary: Deployment Model•Nodes, their characteristics, and connections•Initial mapping of active classes onto nodes•Architectural view of deployment


View Full Document

FIU CEN 5011 - I/O of Designing a Clas

Download I/O of Designing a Clas
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view I/O of Designing a Clas and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view I/O of Designing a Clas 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?