meljun cortes jedi slides-4.6 component-level design
TRANSCRIPT
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
1/16
Software Engineering 1
Design Engineering
Component-levelDesign
TOPIC SIX
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
2/16
Software Engineering 2
Component-level Design
It defines the data structure, algorithms, interfacecharacteristics, and communication mechanism allocated toeach software component.
A component is the building block for developing computersoftware. It is a replaceable and almost independent part ofsoftware that fulfills a clear function in the context of a well-defined architecture.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
3/16
Software Engineering 3
Basic Component Design
Principles The Open-Close Principle
Components should be extended without the need to modify theinternal structure and behavior of the component.
Liskov Substitution Principle A class can use the derived class as a substitute to the base class.
Dependency Principle
Class should be dependent on abstractions.
Interface Segregation Principle Develop classes that are specific rather than general purpose.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
4/16
Software Engineering 4
Component-level Design
Guidelines Component
Architectural component names should come from the problemdomain and is easily understood by the stakeholders, particularly,the end-users. As an example, a component called Application is
clear to any one reading the component. Implementation component name should come from the
implementation specific name. As an example, Athlete is thepersistent class for a record of an athlete.
Use stereotypes to identity the nature of the component such as
, or .
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
5/16
Software Engineering 5
Component-level Design
Guidelines Interfaces
The canonical representation of the interface is recommended whenthe diagram becomes complex.
They should flow from the left-hand side of the implementingcomponent.
Show only the interfaces that are relevant to the component underconsideration.
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 interfacerather than component to component.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
6/16
Software Engineering 6
Component Diagram
It is a diagram used to model software components, theirdependencies, hierarchies and interfaces.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
7/16
Software Engineering 7
Developing the Software
Components1. Refine all classes.a) If necessary, redefine the sequence and collaboration diagrams.
b) Distribute the operations and refine the operation signature.
c) Refine attributes of each class.
d) Identity visibility.
e) Document the class.
2. Refine the packaging of the classes.
3. Define the software components.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
8/16
Software Engineering 8
STEP 1: Refine all classes.
The classes are refined in such a way that they are unifiedand at the same time, it can be easily translated into aprogram.
Steps involved are:
Refine the sequence and collaboration diagrams if necessary.
Distribute and refine the operation signatures.
Refine attributes.
Identify visibility of attributes and operations.
Document the class.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
9/16
Software Engineering 9
MaintainAthleteRecord
Hierarchy
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
10/16
Software Engineering 10
Attribute and Operation
Visibility Visibility specifies whether an attribute or operation is or is notaccessible.
It uses the following symbols.
VisibilitySymbols
Descriptions
+PUBLIC. The attribute or operation isdirectly accessible to an instance of aclass.
-PRIVATE. The attribute or operation isonly accessible to the instance of theclass that includes it.
#
PROTECTED. The attribute or
operation may be used either byinstances of the class that includes it orby a subclass of the class.
~PACKAGE. The attribute or operationis only accessible only be instances of aclass in the same package.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
11/16
Software Engineering 11
Sample Controller Class
Definition
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
12/16
Software Engineering 12
STEP 2: Refine the packaging
of the classes. It might be necessary to redistribute the classes among the
layers and partitions of the software architecture.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
13/16
Software Engineering 13
STEP 3: Define the software
components. Packages are the software components.
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
14/16
Software Engineering 14
Club Membership
Maintenance Components 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
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
15/16
Software Engineering 15
Club Membership
Maintenance Components DBClasses (abl.athlete.dbclass) DBAthlete.java
Persistent Classes (abl.athlete.pc)
Athlete.java Guardian.java
PCLAthlete.java
-
7/31/2019 MELJUN CORTES JEDI Slides-4.6 Component-Level Design
16/16
Software Engineering 16
Summary
Basic Component Design Principles Component-level Design Guidelines
Component Diagram
Developing the Software Component Design