J.E.D.I
specific name. As an example, PCLAthlete is the persistent class list for the athletes.
• Use stereotypes to identity the nature of the component such as table, database or screen.
2. Interfaces • The canonical representation of the interface is recommended when the
diagram becomes complex. • They should flow from the left-hand side of the implementing component.
• Show only the interfaces that are relevant to the component under consideration.
3. Dependencies and Inheritance • Dependencies should be modeled from left to right.
• Inheritance should be modeled from bottom subclass or derived class to top superclass or base class.
• Component interdependence are modeled from interface to interface rather than component to component.
4.6.3 Component Diagram
The Component Diagram is used to model software components, their interface, dependencies and hierarchies. Figure 4.55 shows the notation of the this diagram.
A component is represented by a rectangular box with the component symbol inside. The dependency is depicted by the broken arrow. The dependency can be named. The
Client Component is dependent on the Supplier Component.
4.6.4 Developing the Software Component
All classes identified so far should be elaborated including the screens, and data design classes. In this section, the MaintainAthleteRecordController will be used as an
Software Engineering 191
Figure 4.55 Component Diagram Notation
J.E.D.I
example but the component design should be done for all classes.
The MaintainAthleteRecordController is an abstract class that represents, in general, behavior of maintaining an athlete record. It is extended by a type of maintenance-
adding a record, editing a record or deleting a record. Figure 4.56 shows the hierarchy of the type of athlete record maintenance that is modeled during the requirements
engineering phase. The relationship is “is-a-kind” relationship; AddAthleteController is a kind of MaintainAthleteRecordController.
Developing the component-level design involves the following steps. STEP 1: Refine all classes.
The classes are refined in such a way that it can be translated into a program. Refactoring may be required before proceeding. This step involves a series of sub-steps.
STEP 1.1: If necessary, redefine the sequence and collaboration diagrams to reflect the interaction of the current classes.
STEP 1.2: Distribute operations and refine operation signature of the class. Use data types and naming conventions of the target programming language. Figure
4.57 shows the elaboration of the operation signature of the
AddAthleteController
. A short description is attached to the operation. STEP 1.3: Refine attributes of each class. Use data types and naming
conventions of the target programming language. Figure 4.57 shows the elaboration of the attributes of the AddAthleteController. A short description is
attached to the attribute.
STEP 1.4: Identify visibility of the attributes and operations. The visibility symbols are enumerated in Table 24.
Software Engineering 192
Figure 4.56 MaintainAthleteRecordController Hierarchy
J.E.D.I
Visibility Symbols
Descriptions
+ or
public PUBLIC. The attribute or operation is
directly accessible to an instance of a class.
- or
private PRIVATE. The attribute or operation
is only accessible to the instance of the class that includes it.
or protected
PROTECTED. The attribute or
operation may be used either by instances of the class that includes it
or by a subclass of the class.
~ PACKAGE.
The attribute or operation is only accessible only be
instances of a class in the same package.
Table 24: Attribute or Operation Visibility
Visibility symbols are placed before the name of the attribute or operation. See Figure 4.57 as an example.
STEP 1.5: Document the class. Particularly, identify the pre-conditions and post- conditions. Pre-conditions are the conditions that must exists before the class
can be used. Post-conditions are the conditions that exists after the class is used. Also, include the description of the attributes and operations.
Software Engineering 193
Figure 4.57 Controller Class Definition
J.E.D.I
STEP 2: If necessary, refine the packaging of the classes. In our example, it was decided that no repackaging is necessary.
STEP 3. Define the software components. Define the components using the component diagram. Figure 4.58 shows the software
components of the Club Membership Maintenance System. It does not include components that are reused.
The naming of the packages follows the convention used by the Java Programming Language. The package abl.athlete handles the Club Membership Maintenance
System . The list below contains the packages and files
• User-interface Package abl.athlete.ui • AthleteRecordUI.java
• AthleteListUI.java • FindAthleteRecordUI.java
• Controllers abl.athlete.con • MaintainAthleteRecord.java
• AddAthlete.java • EditAthlete.java
• DeleteAthlete.java • FindAthleteRecord.java
Software Engineering 194
Figure 4.58 Club Membership Maintenance Component
Diagram
J.E.D.I
• DBClasses abl.athlete.dbclass • DBAthlete.java
• Persistent Classes abl.athlete.pc • Athlete.java
• Guardian.java The ABL Database is the database server that contains the data that is needed by the
applications.
Software Engineering 195
J.E.D.I
4.7 Deployment-level Design
