A UML-based Object-Oriented Framework Development Methodology
Young Jong Yang, Soon Yong Kim, Gui Ja Choi
Eun Sook Cho, Chul Jin Kim, Soo Dong Kim
Software Engineering Department
Dept. of Computer Science
ETRI Computer & Software Technology Laboratory
Soongsil University
Daejon, Korea 305-333
Seoul, Korea 156-743
[email protected]
[email protected]
Abstract Recently, object-oriented (OO) frameworks have been known to be highly effective [Fay97] and practical for software reuse; as shown in San Francisco project, a large-scaled industry project for framework development [IBM97]. However, systematic development process and detailed instructions for building OO frameworks have not been studied enough. In addition, it has not been clearly defined how to apply OMG’s Unified Modeling Language(UML) in building OO frameworks. In this paper, we propose a practical OO development process that extends UML notations and semantics. The proposed process consists of four typical software development phases; analysis, design, implementation and testing, and each phase is defined as a logical sequence of development tasks. In order to help the seamless migration from one task to subsequent tasks, we provide instructions for carrying out tasks. Since the proposed process is based on UML diagrams and the basic Objectory process, we believe that OO frameworks can be more efficiently developed by utilizing the proposed process, and higher quality OO frameworks can be produced. In order to show the applicability and effectiveness of the process, we present a case study of Electronic Commerce application.
1. Introduction As the size and complexity of system are increasing, the development cost is sharply increasing. Therefore, effective reuse technology becomes more important. Reuse of software has been one of the main goals of software development for decades. However, the early approaches, e.g. function and procedure libraries, only provided reuse of small, building-block components.
With an emergence of the object-oriented paradigm, an important enabling technology for reuse of larger components became available and resulted in the definition of object-oriented framework. An object-oriented framework is defined as a set of classes that embodies an abstract design for solutions to a family of related problems [Joh88]. A running application can be developed by extending framework classes or by plugging application-specific objects into designated slots. To develop such OO frameworks, it is desirable to have a systematic framework development methodology. Traditional object-oriented design methods such as OMT [Rum91] or UML [RAT97] only deal with the design of specific applications, but do not deal with the analysis and design of framework. Recently, much concern of framework focuses on analysis and design method, but current framework methods only provide outline of framework analysis and design. They do not provide stepwise development process and concrete analysis and design guidelines. Therefore, we define a framework development process, and propose concrete analysis and design techniques. Section 2 of the paper gives an overview of objectoriented framework and related works of framework development methods. Section 3 explains the development process and analysis/design method and guidelines for OO framework. Section 4 presents a case study of the methodology applied to Electronic Commerce domain.
2. Related Work 2.1. Overview of Object-Oriented Framework
Object-oriented framework is often characterized as a set of abstract and concrete classes that collaborates, and it provides the skeleton of an implementation for an application. The concrete classes in the framework are intended to be invisible to the framework user. An abstract class is either intended to be invisible to the framework user or intended to be sub-classed by the framework user. The latter classes are also referred to as hot-spots [Pre94]. Frameworks are categorized variously according to a basis point. According to domain dependency, frameworks are classified into vertical and horizontal frameworks. A framework dependent on specific domain is referred to as vertical framework. A framework independent on specific domain is referred to as horizontal framework. Also, some authors categorize frameworks into white box and black box framework. In a white box (inheritance-based) framework, the framework user is supposed to customize the framework behavior through sub-classing of framework classes. On the other hand, a black box framework requires deep understanding of the fixed and variant aspects of the domain [Rob96].
2.2. Existing Framework Development Methods 2.2.1. Designing
a
Framework
by
Stepwise
Generalization When they design a framework, their main concern is to recognize things that should be kept flexible. These are called the hot spots of the framework [Pre94]. In order to identify variant parts, some of questions are proposed as follows: 1) Which concepts of the problem domain exist in variants and should be treated uniformly? 2) Is it possible to find a concrete concept that can be generalized? 3) Which parts of the system might change? 4) Where might a user want to hook custom code into the framework? The author suggests a two-phase design method to build an initial version of a framework; the first phase is called problem generalization and the second phase is called framework design [Kos97]. Problem generalization starts from the specification of a representative application of the intended framework, and generalizes it in a sequence of steps into the most general form. During the second phase the generalization levels of the previous phase are considered in reverse order leading to an implementation for each level. The one of limitations of this method is that essential tasks to problem generalization or framework design are not defined concretely. Also, concrete guidelines to identify hot spot are not described in this method.
2.2.2. Development Process based on Application Experiences This method is a pragmatic framework development approach [Wil93]. First develop n, say two, applications in the problem domain. Identify the common features in both applications and extract these into a framework. To evaluate whether the extracted features are the right ones, redevelop the two applications based on the framework. The advantage of this method is that the framework development is easy, because we extract commonalties from pre-built applications through building applications previously. Whereas it requires much of time to build framework in the case of complex or large domain, and it is difficult to evaluate whether extracted commonalties are right ones. 2.2.3. Development Process based on Domain Analysis The first activity is to analyze the problem domain to identify and understand well-known abstractions in the domain [Wil93]. Analyzing the domain requires analyzing existing applications and the analysis of existing applications will also take a large portion of the budget. After the abstractions have been identified, develop the framework together with a test application, then modify the framework if necessary. Next, develop a second application based on the framework. Identifying commonalties through domain analysis, we can extract well-defined abstract concept, whereas this method requires much of time and budget because of domain analysis.
3. UML-based Object-Oriented Framework Development Process 3.1. Overview of Process As given in Figure 1, framework development process consists of four phases (e.g. analysis, design, implementation, testing), and tasks for each phase are defined. Analysis phase consists of making framework requirement specification (FRS) through extracting common functionality from a set of similar application requirement specifications (ARSs) and identifying frameworks. Design phase consists of identifying classes and hot spots in frameworks, determining black box, white box, or hybrid box approach to design framework, and documenting frameworks. Framework development process is applied repeatedly and incrementally. As depicted in Figure 1, framework grows by adding new functions within each development cycle. Each cycle tackles a relatively small set of
framework requirements, proceeding through analysis, design, implementation, and testing in Figure 1. The framework grows incrementally as each cycle is completed. Also, tasks in each phase are iterated. $QDO\VLV 3KDVH 7DVN 7DVN
&ROOHFW &ROOHFW VLPLODU VLPLODU $56V $56V
7DVN 7DVN
'HVLJQ 3KDVH
3DUWLWLRQ 3DUWLWLRQ
7DVN 7DVN
8VH 8VH &DVHV &DVHV
7DVN 7DVN 7DVN 7DVN
7DVN 7DVN
0DNH 0DNH )56 )56
0DNH 0DNH
8VH 8VH &DVH &DVH 0RGHOLQJ 0RGHOLQJ
7DVN 7DVN
7DVN 7DVN
0DNH 0DNH
&RQFHSWXDO &RQFHSWXDO $' $'
0DNH 0DNH 6HTXHQFH 6HTXHQFH
7DVN 7DVN
7DVN 7DVN
7DVN 7DVN
,GHQWLI\ ,GHQWLI\ +RW +RW 6SRW 6SRW
0DNH 0DNH 6HTXHQFH 6HTXHQFH
GHVLJQ GHVLJQ SDWWHUQV SDWWHUQV
7DVN 7DVN
,PSOHPHQW ,PSOHPHQW
:KLWH%ODFNER[ :KLWH%ODFNER[
,PLWDWH ,PLWDWH $SSOLFDWLRQ $SSOLFDWLRQ
'RFXPHQW 'RFXPHQW )UDPHZRUN )UDPHZRUN
0DNH 0DNH )UDPHZRUN )UDPHZRUN 'LDJUDP 'LDJUDP
7DVN 7DVN
0DNH 0DNH 'HVLJQ 'HVLJQ 6SHFLILFDWLRQ 6SHFLILFDWLRQ
3.2.3. Making Use Case Modeling
7HVWLQJ 3KDVH 7DVN 7DVN
)UDPHZRUN )UDPHZRUN
7DVN 7DVN
:RUN :RUN WKURXJK WKURXJK
)UDPHZRUN )UDPHZRUN 'HVLJQ 'HVLJQ
7DVN 7DVN
'HWHUPLQH 'HWHUPLQH
7DVN 7DVN
'LDJUDP 'LDJUDP IRU IRU )UDPHZRUN )UDPHZRUN
,PSOHPHQWDWLRQ 3KDVH
7DVN 7DVN
,GHQWLI\ ,GHQWLI\ DSSOLFDEOH DSSOLFDEOH
7DVN 7DVN
'LDJUDP 'LDJUDP IRU IRU $SSOLFDWLRQ $SSOLFDWLRQ
&OXVWHU &OXVWHU
8VH 8VH &DVHV &DVHV
0DNH 0DNH &ODVV &ODVV 'LDJUDP 'LDJUDP
7DVN 7DVN
specific from the extracted functional requirements. Functional requirements specified commonly in all ARSs become general part, and they are marked with ‘G’(e.g. G: Order Product). Functional requirements specified in a few ARSs become specific part, and they are marked with ‘S’(e.g. S: Trace Delivery). We make FRS based on general parts(‘G’-added functional requirements). Through this task, we can identify potential hot spots. The contents of FRS consist of the name of functional requirement, overview, and workflow.
This task is also divided into two cases. If there exist ARSs and FRS, we perform use case modeling for FRS. If there are no existing ARSs or incomplete ARSs, we apply use case modeling with ARSs. The latter is depicted in Figure 3.
8QLW 8QLW 7HVWLQJ 7HVWLQJ
,QWHJUDWLRQ ,QWHJUDWLRQ 7HVWLQJ 7HVWLQJ
Figure 1. Framework Development Process * 8VH FDVH
* 8VH FDVH 6 8VH FDVH
* 8VH FDVH
* 8VH FDVH 6 8VH FDVH
3.2. Analysis Phase
$FWRU D
$FWRU D
$FWRU E 6 8VH FDVH
6 8VH FDVH 6 8VH FDVH
Analysis phase consists of six phases whose tasks and workflow among tasks are depicted in Figure 2.
8VH &DVH 'LDJUDP IRU $SSOLFDWLRQ $
8VH &DVH 'LDJUDP IRU $SSOLFDWLRQ %
´,GHQWLI\ FRPPRQ 8VH &DVHV EHWZHHQ DSSOLFDWLRQVµ
3.2.1. Collecting Similar Application Requirement * 8VH FDVH
Specifications(ARSs) This task is to extract commonalties among several applications, and it is divided into two cases. 7DVN 7DVN
7DVN 7DVN
7DVN 7DVN
&ROOHFW &ROOHFWVLPLODU VLPLODU $56V $56V
0DNH 0DNH )56 )56
0DNH 0DNH 8VH 8VH &DVH &DVH 0RGHOLQJ 0RGHOLQJ
7DVN 7DVN
7DVN 7DVN
3DUWLWLRQ 3DUWLWLRQ 8VH 8VH &DVHV &DVHV &OXVWHU &OXVWHU 8VH 8VH &DVHV &DVHV
7DVN 7DVN 0DNH 0DNH &RQFHSWXDO &RQFHSWXDO $FWLYLW\ $FWLYLW\ 'LDJUDP 'LDJUDP
Figure 2. Analysis Phase If there exist application requirement specifications for a specific domain, we collect only a set of ARSs. If there are no existing ARSs or incomplete ARSs, we perform walkthroughs of current workflow for domain through user interviews, and we make ARS based on functional requirements identified by user interviews. 3.2.2. Making
Framework
Requirement
Specification(FRS) We extract only functional requirements from a set of ARSs because a framework focuses on functional requirements. We identify what is general and what is
* 8VH FDVH
$FWRU D
8VH &DVH 'LDJUDP IRU )UDPHZRUN
Figure 3. Use Case Modeling for ARSs To make a use case model, we should initially identify actors. To identify actor, we extract noun, subject, or application module name which occurs event in system environment or requests task in FRS by using UML use case notation. And then, we identify use cases by listing all events from the outside environment to which we want to react. Then, we define links between actors and use cases or between use cases, and write use case description for each use case. In case of making use case modeling for each application, we add ‘G’ into common use cases and add ‘S’ into specific use cases. We make use case diagram for framework based on common use cases extracted from use case diagrams for ARSs. 3.2.4. Partitioning Use Cases In this task, we determine the layers of uses cases based on the degree of generality and specialty for each use case. Layer is divided into three layers, which are foundation layer, common business layer, and core business layer (Figure 4). Foundation layer consists of frameworks that provide system services. Common
business layer consists of frameworks that provide business objects used in various domains. Core business layer consists of frameworks that provide common functions for a specific domain. After determining layers, we assign each use case into each layer. Use cases contained in foundation layer are independent in business domain, and they become horizontal frameworks. &RPPRQ %XVLQHVV /D\HU
&RUH %XVLQHVV /D\HU
9HUWLFDO +RUL]RQWDO
3.3. Design Phase )RXQGDWLRQ /D\HU
8VHV!! * 8VH FDVH
* 8VH FDVH
* 8VH FDVH
8VHV!!
Identifying event flow described in use case description, we can define sequence between activities. As given in Figure 5, we can express workflow between use cases as well as workflow between frameworks in a conceptual activity diagram. If use cases are very abstract, we decompose use case into concrete use cases.
* 8VH FDVH
H[WHQGV!! * 8VH FDVH
Design phase of framework consists of ten tasks, and they are iterated (Figure 6). 7DVN 7DVN
* 8VH FDVH
H[WHQGV!! * 8VH FDVH
0DNH 0DNH
7DVN 7DVN
&ODVV 'LDJUDP &ODVV 'LDJUDP
'HWHUPLQH 'HWHUPLQH :KLWH%ODFNER[ :KLWH%ODFNER[
* 8VH FDVH
* 8VH FDVH
7DVN 7DVN
0DNH 6HTXHQFH 0DNH 6HTXHQFH
'LDJUDP IRU $SSOLFDWLRQ 'LDJUDP IRU $SSOLFDWLRQ
7DVN 7DVN
0DNH 0DNH
)UDPHZRUN 'LDJUDP )UDPHZRUN 'LDJUDP
* 8VH FDVH
7DVN 7DVN
,GHQWLI\ +RW 6SRW ,GHQWLI\ +RW 6SRW
Figure 4. Partitioning Use Cases into Layers 7DVN 7DVN
3.2.5. Clustering Use Cases This task is to identify frameworks. We should cluster related use cases into each layer. The criteria for clustering use cases is as following: 1) Use cases that have independent functionality are not contained in any cluster. 2) Use cases that have “extends” relationship are contained in the same cluster. 3) Use cases that have “uses” relationship are contained in the same cluster. Through above criteria, each cluster becomes one framework. After we integrate use case descriptions for each use case, we make use case description for each framework, and refine use case diagram for each framework. 3.2.6. Making Conceptual Activity Diagram First of all, we map each use case in a framework into one activity. )UDPHZRUN $! 8VH &DVH
8VH &DVH
0DNH 6HTXHQFH 0DNH 6HTXHQFH
'LDJUDP IRU )UDPHZRUN 'LDJUDP IRU )UDPHZRUN
8VH &DVH
8VH &DVH
8VH &DVH
8VH &DVH
)UDPHZRUN %!
7DVN 7DVN
,GHQWLI\ ,GHQWLI\
7DVN 7DVN
0DNH 0DNH
'HVLJQ 6SHFLILFDWLRQ 'HVLJQ 6SHFLILFDWLRQ
7DVN 7DVN
:RUN WKURXJK :RUN WKURXJK
)UDPHZRUN 'HVLJQ )UDPHZRUN 'HVLJQ
7DVN 7DVN
'HVLJQ 3DWWHUQV 'HVLJQ 3DWWHUQV
'RFXPHQW 'RFXPHQW )UDPHZRUN )UDPHZRUN
Figure 6. Design Phase 3.3.1. Making Class Diagram We identify candidate classes from each ARS through listing noun or subject in ARS. Next, we should identify candidate relationships between classes through listing verb or verb phrase described in ARS and FRS. And then, we identify attributes, which correspond to nouns followed by possessive phrases and identify candidate operations through extracting actions or functions in candidate relationships. We make class diagram based on identified classes, relationships, attributes, and candidate operations. 3.3.2. Making Sequence Diagram for Application The purpose of making sequence diagram for each ARS is to extract operations for classes in ARS. To make sequence diagram, we should arrange classes based on scenarios described in use case descriptions. Next, we should identify messages between classes. To do it, correspond event flows described in scenarios to messages. After identifying messages, we should map receiving messages to a class into member functions of it. 3.3.3. Identifying Hot Spot
Figure 5. Conceptual Activity Diagram for Framework
First of all, we should extract classes, which have common attributes and operations from class diagrams, and identify hot spot for ARSs. Next, we define common abstract class for these classes and represent relationship
between common class and subclasses that have common attributes and operations as inheritance. After result, common attributes and operations are moved in abstract class. This process is described in Figure 7. &ODVV %03
&ODVV -3(*
'LVSOD\
'LVSOD\
'LVSOD\
$SSOLFDWLRQ
&ODVV *,)
$SSOLFDWLRQ
$SSOLFDWLRQ
DEVWUDFW!! &ODVV ' 'LVSOD\
+RW 6SRW
Figure 7. Identifying Hot Spot After defining abstract class, we should define function signatures for functions in abstract classes because some of functions can be implemented differently according to application, on the other hand, other functions can be implemented uniformly in all applications. Function signatures are classified into virtual (e.g.V:foo( )), concrete (e.g. C:foo( )) and abstract (e.g. A:foo( )). Virtual function has only function signatures in abstract class and its body is implemented differently in each application. Concrete function is mapped into functions implemented fixedly in all application classes. Abstract function has a few implementations as well as a few calling virtual functions in function body. Signatures for functions are reflected on class diagram.
through class diagram. We can select different approaches according to hot spots. White box approach is as following: When hot spots conform to core business layer (or vertical layer) or there are a number of subclasses inherited by abstract class, we should design framework with white box approach. A case of designing framework with black box approach is as following: Above all, we should design classes that have fixed implementations with black box approach. That is, concrete classes contained in framework should be designed with black box. Also, when hot spot is contained in horizontal layer, it should be designed with black box approach. In the third case, if there are a few of subclasses inherited from abstract classes, they are designed with black box. A case of designing framework with black and white box approach is as following: When hot spot is contained in common business layer, fixed parts should be designed with black box approach, and variant parts should be designed with white box approach. 3.3.7. Making Framework Diagram The purpose of this task is to define framework interfaces for each framework and assign control flows between classes in a framework. After grouping relevant classes in a framework, we should assign control flows into classes based on messages in sequence diagram for framework. 2EMHFW $
2EMHFW %
2EMHFW &
2EMHFW '
&ODVV &
&ODVV %
PVJ
)BI PVJ PVJ
3.3.4. Making Sequence Diagram for Framework
)BI
PVJ
To make sequence diagram for framework, we arrange classes in a framework, application that uses framework, or other frameworks which use it. Next, we should identify messages through event flows described in use case description for framework. We map each of messages into classes in framework, application, or other framework. The purpose of making sequence diagram for framework is to identify applicable design patterns and identify control flows between classes in framework. 3.3.5. Identifying Applicable Design Patterns We identify applicable design patterns in sequence diagram for framework in previous task. We make mapping table for identified patterns, with matching classes in class diagram with the role of classes based on defined patterns ([Gam95],[Rog97]). 3.3.6. Determining White box/Black box Approach Now, we should consider white box, black box, or black and white box approach into framework design
PVJ
)BI &ODVV '
&ODVV $ )BI
PVJ
6HTXHQFH 'LDJUDP!
)UDPHZRUN 'LDJUDP!
Figure 8. Defining Framework Interface And then, we should define framework interfaces for framework designed with black box or black and white box approach. A criterion of defining framework interface is a scenario for use case contained in framework. That is, we define framework interface as a wrapping method of message flows described in sequence diagram (Figure 8). After making framework diagram for each framework, we should define relationships between frameworks. The relationships (e.g. association or aggregation) are identified with sequence diagram and clustered frameworks. 3.3.8. Making Design Specification
This task is to make design specification for classes existed in a framework with pseudo code format. A format of pseudo code is based on Java language syntax. A framework is represented by ‘Package’ and abstract class is represented by ‘Interface’ or ‘Abstract Class’. In the case of declaring abstract class with ‘Interface’, the abstract class has only virtual functions. In the case of declaring abstract class with ‘Abstract Class’, the abstract class has one more concrete functions and virtual functions as well as attributes. Additionally, concrete classes are depicted in ‘Class’ and prefix ‘F_’ is added in framework interface(e.g. F1_find( )). 3.3.9. Reviewing Framework Design This task is a process of refining tasks in framework design repeatedly, with reviewing the mapping among class diagram, sequence diagram, and framework diagram. That is, it reviews consistency between diagrams. 3.3.10.
Documenting Framework
Documenting framework provides formal framework and user manual of framework usage to application developers. Especially, in the case of white box approach, extension points (e.g. hot spots) which application developers extend in specific application should be documented. The contents of framework document are as following: 1) Framework Name: Describe framework name. 2) Framework Type: Describe whether a framework is a vertical, mixed, or not, or whether a framework is a black box, black and white box, or not. 3) Functional Requirements: Describe functional requirements provided in framework (Use Case Unit). 4) Structures: Describe framework diagram. 5) Applied Design Pattern: Describe design pattern applied in framework. 6) Participants: Describe classes contained in framework. 7) Collaborations: Describe sequence diagram for framework. 8) Design Specification: Describe pseudo code for framework. 9) Usage: Describe using method of framework. That is, using method is described according to in the case of black box, white box, and black and white box. In the case of black and white box and white box, extension point should be described.
3.4. Implementation Phase Implementation phase consists of two tasks (Figure 9). First task is to implement classes and interfaces of framework. Implementing framework interface is to implement control flows between classes contained in a
framework. Second task is to build specific application by using implemented framework. This task applies framework to specific application and implements hook method through sub-classing hot spot in the case of white box approach and through composing object into framework. 7DVN 7DVN
,PSOHPHQW ,PSOHPHQW )UDPHZRUN )UDPHZRUN 7DVN 7DVN
,PLWDWH ,PLWDWH $SSOLFDWLRQ $SSOLFDWLRQ
Figure 9. Implementation Phase
3.5. Testing Phase Unit testing is processed in testing phase above all (Figure 10). Unit testing is executed in two types. One is to test classes in framework. The other is to test framework itself. Unit testing for class is to test interfaces of classes, and unit testing for framework is to test whether message passing between classes is executed correctly or not. 7DVN 7DVN
8QLW 8QLW7HVWLQJ 7HVWLQJ
7DVN 7DVN
,QWHJUDWLRQ ,QWHJUDWLRQ 7HVWLQJ 7HVWLQJ
Figure 10. Testing Phase After executing unit testing, integration testing is processed. Integration testing is to test whether message passing between frameworks is executed correctly or not, with integrating frameworks.
4. Case Study and Assessment In this section, we propose a case study for EC (Electronic Commerce) domain applied with proposed framework development process and describe assessment between proposed process and existing development process.
4.1. Case Study Many of Web applications for EC domain have been established. Therefore, we collected similar application requirement specifications and extracted common functions from them. Common functions are ‘Enter order’, ‘Validate user’, ‘Cancel order’, ‘Enter payment’, ‘Validate payment’, etc. Use case diagram for these functions is described in Figure 11. After partitioning use cases into layers, a result of clustering use cases is depicted in Figure 12.
Because clustered use cases became a framework unit, there are three frameworks for EC domain. %URZVH 3URGXFW
9DOLGDWH 8VHU
3URGXFW
9DOLGDWH 3D\PHQW
H[WHQGV!! XVHV!!
6WULQJ SURGXFW,'
&XVWRPHU
6WULQJ SURGXFW1DPH
6WULQJ XVHU,'
6WULQJ SURGXFW&RPSDQ\
6WULQJ XVHU1DPH
/RQJ XQLW3ULFH
6WULQJ DGGUHVV
(QWHU 3D\PHQW
$ GLVSOD\
%DQN
(QWHU
H[WHQGV!! 'HOLYHU\
ERRN
&ORWKH
3D\PHQW )UDPHZRUN
&RPSXWHU 2UGHU)UDPH
3D\PHQW)UDPH
JHWBGHOLYHU\BLQIR
JHWBRUGHUBLG
JHWBSD\PHQWBLQIR
'HOLYHU\ )UDPHZRUN
'HOLYHU 3URGXFW
H[WHQGV!!
$UUD\ FDUGV> @
9 FKDQJH8QLW3ULFH
3URFHVV 3D\PHQW
&DQFHO 2UGHU &DQFHO 3D\PHQW 5HWXUQ 3URGXFW
2UGHU )UDPHZRUN
DEVWUDFW!!
3URGXFW &RPSDQ\
6WULQJ SKRQH
(QWHU 2UGHU
&OLHQW
application developers only deliver object reference into framework interface because hot spot is implemented in framework.
DEVWUDFW!! 3D\PHQW
2UGHU 6WULQJ RUGHU'DWH
'HOLYHU\)UDPH
9 YDOLGDWH3D\PHQW
,QW RUGHU$PRXQW
9 WUDQVIHU
$UUD\ SURGXFWV> @ JHWBRUGHUBLG
6WULQJ GHOLYHU\7\SH 6WULQJ SD\PHQW7\SH
&RQILUP 'HOLYHU\
6KLSSLQJ &RPSDQ\
&UHGLW&DUG
&DVK
0RQGH[
'LJLWDO&DVK
3D\PHQWV
DEVWUDFW!! 'HOLYHU\
9 GHOLYHU 9 UHWXUQ'HOLYHU\ $ FRQILUP'HOLYHU\ 9 FRPSXWH'HOLYHU\&RVW & FKDQJHGHOLYHU\6WDWXV
Figure 11. Use Case Modeling for EC Domain 3RVW
Sequence of among frameworks and workflow of among use cases in a framework are described through conceptual activity diagram (Figure 12). 2UGHU )UDPHZRUN! %URZVH (QWHU 2UGHU 3URGXFW
9DOLGDWH 8VHU
DEVWUDFW!!
3D\PHQW)UDPH
) JHWBSD\PHQWBLQIR
)B(QWHU3D\PHQW
(QWHU 3D\PHQW
3D\PHQW )UDPHZRUN!
'HOLYHU 3URGXFW
) )B9DOLGDWH3D\PHQW 3D\PHQW
RUGHU,' SD\PHQW,'
9DOLGDWH 3D\PHQW 3URFHVV 3D\PHQW
5HWXUQ &RQILUP 3URGXW 'HOLYHU\ 'HOLYHU\ )UDPHZRUN!
Figure 13. Class Diagram for EC Domain
3URFHVV 2UGHU
&DQFHO 2UGHU
&DQFHO 3D\PHQW
'LUHFW 'HOLYHU\
(QWHU 'HOLYHU\
)
9 WUDQVIHU
&DVK
&UHGLW&DUG
)B&DQFHO3D\PHQW
9 YDOLGDWH3D\PHQW
0RQGH[
)
'LJLWDO&DVK
)B3URFHVV3D\PHQW
3D\PHQWV
& YDOLGDWH3D\PHQW
& YDOLGDWH3D\PHQW
& YDOLGDWH3D\PHQW
& YDOLGDWH3D\PHQW
& YDOLGDWH3D\PHQW
& WUDQVIHU
& WUDQVIHU
& WUDQVIHU
& WUDQVIHU
& WUDQVIHU
Figure 12. Conceptual Activity Diagram
Figure 14. Framework Diagram for Payment
Common abstract classes identified in application class diagrams are ‘Product’ class, ‘Payment’ class, and ‘Delivery’ class. ‘Product’ class is a hot spot of ‘Order Framework’, ‘Payment’ class is a hot spot of ‘Payment Framework’, and ‘Delivery’ class is a hot spot of ‘Delivery’ Framework. Class diagram for frameworks based on identified classes is given in Figure 13. The result of determining white box, black and white box, black box approach is as following: ‘Product’ class is designed with white box approach because there are many of classes inherited by ‘Product’ class according to application. ‘Payment’ class is designed with black box, because there are standard classes accepted payment method in EC applications. ‘Delivery’ class also is designed with black box, because there are a few of classes inherited by ‘Delivery’ class. Therefore, in ‘Order Framework’, application developers should implement hot spots through subclassing from abstract class(‘Product’ class). In a ‘Payment Framework’ and ‘Delivery Framework’,
Framework This is executed through dynamic binding. Because ‘Order Framework’ implements hot spot with white box and fixed part with black box, this becomes black and white box framework. On the other hand, ‘Payment Framework’ and ‘Delivery Framework’ become black box framework, because all classes are implemented in framework. The result of making framework diagram is depicted in Figure 14. Figure 14 describes framework diagram and framework interface for ‘Payment Framework’.
4.2. Assessment We propose a comparison and assessment of between proposed framework development process and other development processes. Existing methods describe development phase, task, or guidelines roughly. On the other hand, we defined concrete development phases, tasks, and workflow between tasks in framework
development process as well as concrete guidelines for each task. As described in Table 1, existing methods only provide partial tasks for framework development and don’t describe the task of a framework interface definition and documentation. However, our process provides almost tasks for framework development. Especially, we proposed the method of identifying hot spots, extracting frameworks, and defining framework interfaces. These methods are not described in existing methods. Also, current methods do not apply specific notations to framework development. On the other hand, we applied not only UML notations and semantics to framework development but also produced new framework diagram notation to apply for framework development.
5. Concluding Remarks In this paper, we proposed a practical OO framework development process that is based on UML notations and semantics. We defined development phases and tasks for each phase. We defined essential tasks for framework development and applied UML notations to each task. Each task is given a set of instructions on how to carry out the task. In order to help the seamless migration from one task to subsequent tasks, we provided instructions for task migration. Since the proposed process is based on UML diagrams and the basic Objectory process, we believe that OO frameworks can be more efficiently developed by utilizing the proposed process, and higher quality OO frameworks can be produced.
Table 1. Comparison of among Framework Development Processes Methods Contents Development process definition Framework Identification Hot Spot Identification Black/White box Identification Design Pattern Identification Framework Inteface Framework Document
Stepwise Generalization Partially Partially Partially Partially Partially No No
Based on Applciation experience Partially Partially Partially No No No No
R.E. Johnson, B. Foote, “Designing Reusable Classes,” Journal of Object-Oriented Programming, Vol. 1, No. 2, June 1988.
[Joh92]
R.E. Johnson, “Documenting Frameworks with Patterns,” Proceedings of the 7th Conference on OOPSLApplications, Vancouver, Canada, 1992.
[Gam95]
E. Gamma, R. Helm, R. Johnson, J.O. Vlissides, Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley, 1995.
[Rob96]
D. Roberts, R. Johnson, “Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks,” Proceedings of the Third Conference on Pattern Languages and Programming, Montecillio, Illinois, 1996.
[Rum91]
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice-Hall, 1991.
[Kos97]
K. Koskimies, H. Mössenböck, “Designing a Framework by Stepwise Generalization”, 1997.
[Pre94]
W. Pree, “Meta Patterns – A means for capturing the essential of reusable object-oriented design,” Proceedings of the 8th European Conference on Object-Oriented Programming, Bologna, Italy, 1994.
Proposed Process Yes Yes Partially Partially Yes Yes Yes
[Spa96]
S. Sparks, K. Benner, C. Faris, “Managing ObjectOriented Framework Reuse,” IEEE Computer, pp.5361, September 1996.
[Wil93]
D. A. Wilson, S. D. Wilson, “Writing Frameworks – Capturing Your Expertise About a Problem Domain,” Tutorial notes, The 8th Conference on ObjectOriented Programming Systems, Languages and Applications, Washington, 1993.
[RAT97]
Rational Software Corp., Unified Language(UML) Summary, 1997.
[Rog97]
G. F. Rogers, Framework-based Software Development in C++, Prentice-Hall, 1997.
[IBM97]
IBM Corp., “San Francisco Project Technical Summary,” http://www.ibm.com/Java/Sanfrancisco/prd_summary. html, 1997.
[Fay97]
M. E. Fayad and D. C. Schmidt, “Object-Oriented Application Frameworks,” Communication of the ACM, Vol. 40, No. 10, October 1997.
6. [References] [Joh88]
Based on Domain Analysis Partially Partially Partially No No No No
Modeling
