Chapter 11
Component-Level Design
- Introduction
- The software component
- Designing class-based components
- Designing conventional components
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Component-Level Design: A Structured Approach to Software Development, Exercises of Software Engineering
An in-depth exploration of component-level design, a crucial aspect of software engineering. Component-level design involves creating modular, deployable, and replaceable parts of a system, represented through various views such as object-oriented, conventional, and process-related. Principles and guidelines for designing software components, including object-oriented design, conventional design, and process-related design. It also discusses component packaging principles and cohesion and coupling in component design.
Typology: Exercises
2016/2017
1 / 26
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Component-Level Design: A Structured Approach to Software Development and more Exercises Software Engineering in PDF only on Docsity!
Chapter 11
Component-Level Design
- (^) Introduction
- (^) The software component
- (^) Designing class-based components
- (^) Designing conventional components (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Introduction
The Software Component
Defined
- (^) A software component is a modular building block for computer software - (^) It is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces
- (^) A component communicates and collaborates with
- (^) Other components
- (^) Entities outside the boundaries of the system
- (^) Three different views of a component
- (^) An object-oriented view
- (^) A conventional view
- (^) A process-related view
7
Conventional View
- (^) A component is viewed as a functional element (i.e., a module) of a
program that incorporates
- (^) The processing logic
- (^) The internal data structures that are required to implement the processing logic
- (^) An interface that enables the component to be invoked and data to be passed to it
- (^) A component serves one of the following roles
- (^) A control component that coordinates the invocation of all other problem domain components
- (^) A problem domain component that implements a complete or partial function that is required by the customer
- (^) An infrastructure component that is responsible for functions that support the processing required in the problem domain (More on next slide)
Conventional View (continued)
- (^) Conventional software components are derived from the data flow diagrams (DFDs) in the analysis model
- (^) Each transform bubble (i.e., module) represented at the lowest levels of the DFD is mapped into a module hierarchy
- (^) Control components reside near the top
- (^) Problem domain components and infrastructure components migrate toward the bottom
- (^) Functional independence is strived for between the transforms
- (^) Once this is completed, the following steps are performed for each transform
- Define the interface for the transform (the order, number and types of the parameters)
- Define the data structures used internally by the transform
- Design the algorithm used by the transform (using a stepwise refinement approach)
Designing Class-Based
Components
Component-level Design Principles
- (^) Open-closed principle
- (^) A module or component should be open for extension but closed for modification
- (^) The designer should specify the component in a way that allows it to be extended without the need to make internal code or design modifications to the existing parts of the component
- (^) Liskov substitution principle
- (^) Subclasses should be substitutable for their base classes
- (^) A component that uses a base class should continue to function properly if a subclass of the base class is passed to the component instead
- (^) Dependency inversion principle
- (^) Depend on abstractions (i.e., interfaces); do not depend on concretions
- (^) The more a component depends on other concrete components (rather than on the interfaces) the more difficult it will be to extend
- (^) Interface segregation principle
- (^) Many client-specific interfaces are better than one general purpose interface
- (^) For a server class, specialized interfaces should be created to serve major categories of clients
- (^) Only those operations that are relevant to a particular category of clients should be specified in the interface
Component-Level Design
Guidelines
- (^) Components
- (^) Establish naming conventions for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model
- (^) Obtain architectural component names from the problem domain and ensure that they have meaning to all stakeholders who view the architectural model (e.g., Calculator)
- (^) Use infrastructure component names that reflect their implementation- specific meaning (e.g., Stack)
- (^) Dependencies and inheritance in UML
- (^) Model any dependencies from left to right and inheritance from top (base class) to bottom (derived classes)
- (^) Consider modeling any component dependencies as interfaces rather than representing them as a direct component-to-component dependency
14
Cohesion
- (^) Cohesion is the “single-mindedness’ of a component
- (^) It implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself
- (^) The objective is to keep cohesion as high as possible
- (^) The kinds of cohesion can be ranked in order from highest (best) to lowest (worst) - (^) Functional - (^) A module performs one and only one computation and then returns a result - (^) Layer - (^) A higher layer component accesses the services of a lower layer component - (^) Communicational - (^) All operations that access the same data are defined within one class (More on next slide)
Coupling
- (^) As the amount of communication and collaboration increases between operations and classes, the complexity of the computer-based system also increases
- (^) As complexity rises, the difficulty of implementing, testing, and maintaining software also increases
- (^) Coupling is a qualitative measure of the degree to which operations and classes are connected to one another
- (^) The objective is to keep coupling as low as possible (More on next slide)
Coupling (continued)
- (^) The kinds of coupling can be ranked in order from lowest (best) to highest (worst) - (^) Data coupling - (^) Operation A() passes one or more atomic data operands to operation B(); the less the number of operands, the lower the level of coupling - (^) Stamp coupling - A whole data structure or class instantiation is passed as a parameter to an operation - (^) Control coupling - (^) Operation A() invokes operation B() and passes a control flag to B that directs logical flow within B() - (^) Consequently, a change in B() can require a change to be made to the meaning of the control flag passed by A(), otherwise an error may result - (^) Common coupling - (^) A number of components all make use of a global variable, which can lead to uncontrolled error propagation and unforeseen side effects - (^) Content coupling - (^) One component secretly modifies data that is stored internally in another component (More on next slide)
Conducting Component-Level Design
- Identify all design classes that correspond to the problem domain as defined in the analysis model and architectural model
- Identify all design classes that correspond to the infrastructure domain
- (^) These classes are usually not present in the analysis or architectural models
- (^) These classes include GUI components, operating system components, data management components, networking components, etc.
- Elaborate all design classes that are not acquired as reusable components a) Specify message details (i.e., structure) when classes or components collaborate b) Identify appropriate interfaces (e.g., abstract classes) for each component c) Elaborate attributes and define data types and data structures required to implement them (usually in the planned implementation language) d) Describe processing flow within each operation in detail by means of pseudocode or UML activity diagrams (More on next slide)
Conducting Component-Level Design (continued)
- Describe persistent data sources (databases and files) and identify the classes required to manage them
- Develop and elaborate behavioral representations for a class or component
- (^) This can be done by elaborating the UML state diagrams created for the analysis model and by examining all use cases that are relevant to the design class
- Elaborate deployment diagrams to provide additional implementation detail
- (^) Illustrate the location of key packages or classes of components in a system by using class instances and designating specific hardware and operating system environments
- Factor every component-level design representation and always consider alternatives
- (^) Experienced designers consider all (or most) of the alternative design solutions before settling on the final design model
- (^) The final decision can be made by using established design principles and guidelines