6. Component Level Design

• What is the component level?

  1. Components are defined during architectural design
  2. Internal data structures and processing details of each component are NOT represented at this level of abstraction
• Component level of Design

  defines:

  • data structure
  • algorithm
  • interface
  • characteristics
  • communication to each component
• What is a component?

  1. Object Oriented view: a component with a set of collaborating classes
  2. Traditional View: has internal processing logic, data structures that are needed to implement processing logic. Also has an interface that lets component be invoked and get data
  3. Process-related view: using reusable software or patterns to build systems
• Components in a component diagram act in what way ?

  They act in a need to know basis. This means each component has one clear aim and only interacts with other essential elements.
• Class-based Component-Level Design

  To make sure all interfaces that allow the classes to communicate and collaborate; start off with a design model and elaborate analysis classes and infrastructure classes
• Traditional Component Design

  • focused on how the software product operates and the components around it that are needed to complete the product.
  • Examples are: database access, security, management
  • Components are first defined in a hierarchical manner
  • start by defining components that focus on control
  • Problem domain components are at the bottom of the hierarchy
• There are 3 main component roles

  1. Control- A component that coordinates how components of all other problem domains are invoked
  2. A component that implements a complete or partial function that the customer requires
  3. Infrastructure:-A component that is responsible for functions that help processing that the problem domain requires
• The Open Closed Principle (OCP) Component Design Principle

  • module (component) should be open for extension but closed for modification
  • This means you can extended the component in the functional domain without needing to make changes to code or logic of the component
  • Use abstraction to do this- acts as buffer between the function that is being extended and the design class
  • Solution: create a new abstract class and override it for each instance
• The Liskov Substitution Principle (LSP) Component Design Principles

  • Subclasses should be substitutable for their base classes
  • objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program
  • if you pass a component to a subclass instead of the base class it should continue to function properly
  • All pre and post conditions that need to be true for the base class should also be true for the sub classes
• LSP Cont....

  • Violation example: creating a square that extends the rectangle class because you are making the assumption that a Square is a sub-class of a Rectangle and there could be operators defined in rectangle that don't apply to square
  • Solution: Define a Square as a separate Shape (Shape is an Interface that defines a getArea abstract operator
  • Basically get rid of setter operators
• The Dependency Inversion Principle (DIP) Component Design Principle

  • Depend on abstractions not on concrete components
  • The more a component depends on other compoenets (instead of abstractions) the harder it will be to extend it
  • if you dispense design and hack out code (code is the ultimate “concrete implementation.”) You’re violating DIP
  • Ex- only having one delivery driver and he's sick
  • Solution: Create the DeliveryService interface and implement it in the DeliveryDriver
  • Refactor DeliverCompany so that it depends on the DeliverService interface
• The Interface Segregation Principle ISP Component Design Principle

  • A lot of client-specific interfaces are better than one general purpose interface
  • create a specialized interface to serve each major category of clients
• Violation of ISP Example

  • There is a Car Interface and Mustang class that implementsthat Interface.
  • We want to add a new car, DeLorean, that can travel in time so new operators are defined in the Interface.
  • Problem us that Mustang must also implement these operators
  • Solution: add another interface called TimeMachine and have DeLorean implement both interfaces
• The SOLID Principles

  • Were introduced in the early 2000s
  • Mostly applied where interfaces are readily available (OO software/component design)
  • Give us high cohesion and low coupled software that is; easy to maintain, extend, and robust
• The SOLID Principles

  S ingle responsibility principle

  O pen closed principle

  L isikov substitution principle

  I nterface Segregation principle

  D ependency Inversion principle
• Additional Design Principles - Release Reuse Equivalency (REP)

  • the granule of reuse is the granule of release
  • The developer commits to establish a release control system that supports and maintains older versions of the entity while the users slowly upgrade to the most current version
  • Examples: Windows, Ios updates
• Additional Design Principles - Common Closure Principle (CCP)

  • Classes that change together belong together
  • If classes are packed as part of a design then they should address the same functional and behavioral area
• Additional Design Principles - (CRP) Common Reuse Principle

  • Classes that aren’t reused together should not be grouped together.
• Pragmatic Component-Level Design Guidelines

  • Components: naming should be like you would name methods. Naming conventions should be established for components that are part of the architectural model. They should be refined and elaborated as part of the component-level model
  • Interfaces: provide info about communication and collaboration and help us achieve OCP
  • Dependencies and Inheritance: model dependencies from left to right and inheritance from bottom (subclass) to top (parent class).
• Conducting Component-Level Design Steps

  1. Identify design classes in the problem domain
  2. Identify design classes in the infrastructure domain
  3. Elaborate design classes that are not reusable components
  4. (3a) message details when classes/components collaborate
  5. (3b) appropriate interfaces for each component
  6. (3c) Elaborate attributes and define data type and structures required to implement them
  7. (3d) Describe processing flow within each operation
  8. (4) Describe data sources (databases and files) and identify the classes to manage them
• Component-Level Design for WebApps


  WebApp component is

  • a well-defined cohesive function that manipulates content, provides computational or data processing for an end-user.
  • a cohesive package of content and functionality that provides end-user with some capability
  • is both functional and content design
• Traditional Component-Level Design

  • does not encapsulate data the same way as OO components. It focuses on functions and data structures of the software
  • Design of processing logic is based on principles of algorithm design and structured programming rules.
  • Design of data structures is defined by the data model
  • Design of interfaces is dependent on collaborations that a component must effect
• Component-Based Software Engineering (CBSE) benefits

  • Reduced lead time: It is faster to build complete applications from a pool of existing components
  • Greater return on investment (ROI): sometimes its better to purchase components instead of building them fully
  • Leveraged costs of developing components: by reusing components in multiple applications
  • Enhanced quality: Components are reused and tested in many different applications
  • Maintenance of component-based applications: Withcareful engineering, its easy to replace obsolete components with new/enhanced ones.
• CBSE Risks

  • Component selection risks
  • Component integration risks
  • Quality risks
  • Security risks
  • system evolution risks
• Component Refactoring

  • Refactoring components to improve quality is a good practice.
  • It is hard to convince management to expend resources fixing components that are working correctly rather than adding new functionality to them
  • Changing software and not documenting the changes can lead to increasing technical debt.
  • Reducing this technical debt often involves architecturalrefactoring, which is both costly and risky
  • Developers can make of tools to examine change histories to identify the most cost effective refactoring opportunities,