IO of Designing a Class Design a Class

I/O of Designing a Class

Design 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 provide

Outlining 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 slide

Designing 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 model

Identifying 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 plays

Example: Invoice Class • Used in use-cases: – – Pay Invoice: schedule invoice Send Reminder Invoice Buyer: create & submit invoice Each read or change class state

Identifying 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 complex

Describing States • For objects whose behavior is determined by its states, it’s meaningful to describe important state transitions • Example: state change follows strict sequence

Summary: 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 design

Summary: Deployment Model • Nodes, their characteristics, and connections • Initial mapping of active classes onto nodes • Architectural view of deployment model