1. Component-Level Design
Chapter 11
Component-Level Design
Highlights of translating the design model into operational modules/components

2. Component Design - 1 What is it?
Taking the architectural design (high-level abstractions) into a lower-level procedural details. That is, filling the operational details of individual modules of a Structured Design (SD) (or class operations of an OOD).
It is called procedural design (object design in OOP)
What operational details?
- Sequence
- Condition (Decision) Structures
- Repetition (Iterative) Structures

3. Component Design - 2 Why needed?
- To bring the design model closer to the source code of the
implementation language (translation the design to operational elements).
- Help verify correctness of previous layers of the design (data,
architectural, and interface of SD (object and message design of an OOD).
- Reduce potential source code errors in the target code.
- Produce less complex source code that is efficient, readable, testable, and maintainable.

4. Component Design - 3 What is a component?
OMG Unified Modeling Language Specification [OMG01] defines a component as:
“a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”
OO view: a component contains a set of collaborating classes.
Conventional view: a component contains logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.
Component-based development view: a component is an already developed, proven, and tested operational software module – i.e., available for reuse (Ch-30)

5. OO Component Figure 11.1, Page 295 e g m O f S T y F C P r i n t J o bd u c i n ( ) e g m O f S T y F C P r i n t J o b c m p u e a l y s i s c l a s s
OO Component
Figure 11.1, Page 295 b
<
< i n t e r f a c e
>
> r i o t y a l J b C s W O n u m e P c p g ( ) d T k h c o m p u t e J o b c o m p u t e P a g e C o s t ( ) n u m b e r O f P a g e s c o m p u t e P a p e r C o s t ( ) c o m p u t e P r o d C o s t ( ) n u m b e r O f S i d e s p a p e r T y p e c o m p u t e T o t a l J o b C o s t ( ) p a p e r W e i g h t p a p e r S i z e p a p e r C o l o r m a g n i f i c a t i o n c o l o r R e q u i r e m e n t s p r o d u c t i o n F e a t u r e s c o l l a t i o n O p t i o n s b i n d i n g O p t i o n s c o v e r S t o c k
<
< i n t e r f a c e
>
> b l e e d i n i t i a t e J o b p b u i l d W o r k O r d e r ( ) c h e c k P r i o r i t y ( )

6. Conventional Component
Figure 11.3, Page 297

7. OOD View OO Analysis OO Design Implementation OO Testing Deployment
Object
Relationship
Modeling
Class
Behavior
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class Design
Sub-System
Design
Message
Responsibilities

8. Component-Level Design Guidelines
In addition to design Concepts and Principles (Ch-9):
Components
- Naming convention: meaningful names for components and
operations derived from the architectural model.
Interfaces
- Interfaces provide important information about communication
and collaboration
Dependencies and Inheritance (improve readability)
- Model dependencies from left to right and inheritance from
bottom (derived classes) to top (base classes).
- Represent dependencies via interfaces rather than
component-to-component dependency.

9. Again, Cohesion and Coupling
Cohesion and coupling are essential to component-level design.
Conventional view: cohesion is the “single-mindedness” of a module.
OO view: cohesion 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.
Conventional view: coupling is the degree to which a component is connected to other components and to the external world.
OO view: coupling is the a qualitative measure of the degree to which classes are connected to one another.
See page

10. Component-Level Design - 1
Generic Steps (for OOD):
1. Identify all design classes that correspond to the problem domain (classes in the analysis and architectural models).
2. Identify all design classes that correspond to the infrastructure domain (not part of the analysis or architectural models).
3. Elaborate all design classes that are not acquired as reusable components.
Specify message details when classes or components collaborate (from collaboration diagrams).
Identify appropriate interfaces for each class or component.
Elaborate the attributes and define data types and data structures required to implement them.
Describe processing flow within each operation in detail.

11. Component-Level Design - 2
4. Describe persistent data sources (databases and files) and identify the classes required to manage them.
5. Develop and elaborate behavioral representations for a class or component (State/Statechart diagrams).
6. Elaborate deployment diagrams to provide additional implementation detail on the key locations of components.
7. Factor every component-level design representation and always consider alternatives (component internal improvements). (i.e., design is iterative process)
Please see figures 11.6 – 11.9, and 9.7.

12. Object Constraint Language (OCL)
- OCL complements UML by allowing the use of formal grammar and syntax to construct unambiguous statements about various design model elements.
- Simplest OCL language statements are constructed in four parts:
Context: defines the limited situation in which the statement is valid;
Property: represents some characteristics of the context (e.g., if the context is a class, a property can be an attribute)
Operation: manipulates or qualifies a property
Keywords: used to specify conditional expressions

13. OCL Example OCL invariant statement:
context PrintJob::validate(upperCostBound : Integer, custDeliveryReq : Integer)
pre: upperCostBound > 0
and custDeliveryReq > 0
and self.jobAuthorization = 'no‘
post: if self.totalJobCost <= upperCostBound
and self.deliveryDate <= custDeliveryReq
then
self.jobAuthorization = 'yes'
endif

14. Algorithm Design It is the the closest design activity to coding.
Common approach:
review the design description for the component/operation
use stepwise refinement to develop algorithm
use structured programming to implement procedural logic
use ‘formal methods’ to prove the logic

15. Refinement open walk to door; reach for knob; open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

16. Structured Programming
for Procedural Design
Uses a limited set of logical constructs
(sequencing, conditional, loops)
Leads to more readable, testable code.
Important for achieving high quality, but not enough.

17. Representation of Algorithm Design
Procedural design can be represented by different notations.
The goal is to represent the algorithm at a level of detail that can be reviewed for correctness and quality, and is easy to translate to source code.
Representation options:
- Graphical notation (flowchart, box diagram)
- Decision table notation
- Pseudocode notation (PDL) <<choice of many>>
- Programming language syntax
Conduct walkthroughs to assess quality.

18. Flow-Chart Notation a x 1 2 b 3 4 5 c d e f g

19. Decision Tables - 1 Good for representing procedural
details of algorithms with complex
combinations of conditions and
alternative actions.
This notation translates conditions
and actions of a procedure/method
into tabular format.
It helps verify logic and facilitate
testing.
Rules
Conditions 1 2 3 … n
Condition #1
Condition #2
Condition #3
. . .
Actions
Action #1
Action #2
Action #3

20. Decision Tables - 2 Example scenario: (see another example page 318)
“If the customer account is billed using fixed rate method, a minimum monthly charge is assessed for consumption of less than 100 kwh. Otherwise, computer billing applies schedule A rate structure. However, if the account is billed using variable rate method, a schedule A rate structure will apply to consumption below 100 kwh, with additional consumption billed according to schedule B”
Conditions: fixed rate, less than 100 kwh,
variable rate, more than 100 kwh
Actions: min charge, A rate, B rate, and others.

21. Decision Tables - 3 Rules Conditions 1 2 3 4 5 Actions
Fixed rate account T F
Variable rate account
Consumption < 100 kwh
Consumption >= 100 kwh
Actions
Min monthly charge X
Schedule A billing
Schedule B billing
Other Billing Formula

22. Program Design Language - 1
- Easy to combine with source code
- Machine readable, no need for graphics input
- Graphics can be generated from PDL
- Enables declaration of data as well as procedures
- Easier to maintain
if condition x
then process a;
else process b;
endif
PDL
if-then-else

23. Program Design Language - 2
In addition, PDL can be
- a derivative of the high-level programming languages, such as Ada PDL,
- a machine readable and processable,
- embedded with source code and therefore easier to maintain,
- represented in great detail, especially if the designer and coder are different, and
- is easy to review.
See example of PDL syntax page 319.

24. Attributes of a Representation Notation - 1
Attributes to compare and assess a design notation:
- Modularity: Support for modular design.
- Simplicity: Simple to learn and easy to read and use.
- Editing: Support for design changes and software evolution.
- Machine readability: Can be read by computer-based development systems.
- Structure enforcement: Support and enforce the use of structured programming constructs.

25. Attributes of a Representation Notation - 2
- Automatic processing: Can be processed to generate useful information about design correctness and quality.
- Data representation: Ability to represent global and local data structures.
- Logic verification: Ability to verify design logic and improve testing.
- Code-ability: Can be easily converted to source code.

26. Suggested Problems
Consider working the following problems from chapter 11, page 322:
11.1, 11.2, 11.3, 11.7, 11.8, 11.10, 11.12, and
NO submission is required. Work them for yourself!

27. Last Slide
End of Chapter 11