Component Design Elaborating the Design Model

Component Design Translation of the architectural design into a detailed (class-based or module- based) design appropriate for code development Architecture: a.k.a. preliminary design Component: a.k.a. detailed design

Components Defn: modular, deployable, replaceable part of system the encapsulates implementation (function) and exposes an interface OO Design Components are classes (or a package of classes) Nouns within a description of the problem space Conventional Design Components are algorithms (functions) and data structures to support them Types: control, problem domain, infrastructure (also interface) Process (Reuse) View Components are libraries or packages of capability

Design Principles Open-closed Principle: open for extension, closed for modification Liskov Substitution Principle: Derived classes should adhere to conventions of base class Dependency Inversion Principle: Depend on abstractions rather than concretions Interface Segregation Principle: Many specific interfaces are better than one common interface Release Reuse Equivalency Principle: Reuse increases with release support Common Closure Principle: Classes that change together should be packaged together Common Reuse Principle: Classes that are used together should be packaged together

Steps for Component-Level Design Identify design classes in problem domain Identify design classes in infrastructure (support) domain Elaborate design classes (i.e., refine to provide detail) Specify message details between collaborative classes Specify interfaces for components Elaborate class attributes (names and data types) Elaborate operations (including control flow) Describe persistent data sources/sinks Specify infrastructure classes to support data stores Ensure external (user-level) behavior of problem domain classes models requirements Define deployment characteristics (e.g., host environment (h/w, o/s, databases, network constraints), support library versions, deployment mechanism (e.g., install script, zip file) Re-factor design representations considering alternatives

Additional Points of Emphasis We attempt to be systematic in design process and notation to avoid introducing errors in the code (pg 277 7/e, pg 292 6/e) Levels of cohesion (pgs /e, pgs /e) Levels of coupling (pg 289 7/e, pgs /e)