Serbia & Montenegro, Belgrade, November 22-24, 2005
EUROCON 2005
UML-business profile-based Business Modeling in Iterative-Incremental Software Development Drazen Brdjanin* and Slavko Maric** de facto industrial standard for software modeling. Since BM is the first phase in IS development and UML is the standard language for software modeling, extension and use of UML to BM is natural and logical, because during the whole cycle of IS development, from BM to software implementation and transition in business domain, the harmonized notation will be used and transition from business models to system UML models will be easier. At this moment there is no standard for BM based on UML. There are several different approaches [4], but in practice, UML business profile (BP) is used more and more [5].
Abstract - In this paper one approach for business modeling (BM) based on UML business profile (BP) is presented. The static aspect of the BM in the iterativeincremental (I-I) software process development is described and both business models: business use case model and business object model are presented. Dynamic aspect of the BM is presented too, as well as the mechanisms to connect the BM with the other activities in the system development. Some appropriate recommendations for efficient migration of the business models in the initial system UML models are given. Described methodology is wholly integrated in the I-I process, and because of the advantages of the BM based on UML BP, all advantages of the I-I software process development are additionally improved.
Keywords - business modeling, business object model, business use case model, iterative/incremental software development, UML. I. INTRODUCTION
T HE newer, use-case-driven and iterative-incremental (I-I) based approaches to information system (IS) development, for instance as Rational Unified Process (RUP) [1], take the business modeling (BM) as the first phase in the IS development because business model serves for system requirements identification, actually for identification of the most suitable IS architecture for the particular business domain. BM represents the discipline that deals with business domain modeling. A business model is defined as an abstraction of the business domain parts and their relationships. A complete business model usually depicts business domain from different perspectives and it's result of different aspect of analysis [2]. Each view is shown by one or by more different diagrams. Often we talk about the four aspects of analysis: concept (the highest abstraction level view of domain, where the problems and the goal architecture is described), structure (organizational structure of business system), processes (business activities) and behaviour (resources' interactions - workers and objects). UML [3] is the language for visual modeling of software systems. It became the leading modeling language implemented in many CASE tools, and today it's
Fig. 1. Aspects of business domain analysis.
Today, integral software development in "one breath" according to the traditional waterfall model, in real world is impossible and actually unimaginable. An iterative approach is necessary that in sequence of iterations, better domain understanding will be achieved and risk reduced. This approach incrementally leads to goal system. As an example of well structured I-I process with wide application in practice, we often take the RUP. Fig. 2 shows technical perspective of RUP - view from the aspect of activity organization and application of software techniques during the time. RUP has two dimensions: * structural dimension, or static aspect of process represented by activities, resources and artifacts, and * temporal dimension, or dynamic aspect of process represented by phases, iterations, cycles and so on. *
time
Business modeling
Requiremets
Analysis and design
Impolementationb Test
D. Brdjanin, Faculty of Electrical Engineering, University of Banja Luka, Bosnia & Herzegovina (phone: 387-51 -221851; fax: 387-51 -211408; e-mail: bdrazengetfbl.net). S. Maric, Faculty of Electrical Engineering, University of Banja Luka, Bosnia & Herzegovina (phone: 387-51 -221840; fax: 387-51-211408; e-mail:
[email protected]).
1-4244-0049-X/05/$20.00 (C2005 IEEE
1263
Deploymenbt
Fig. 2. Technical perspective of RUP.
II. STATIC ASPECT OF PROCESS A. UML business model Static aspect of process treats necessary activities and resources for realization of particular process' phases, and all artifacts made during those activities, too. The main group of activities (also called workflows or disciplines) are: BM, requirement specification, analysis and design, implementation, test and deployment. Although all these activities look like the phases of traditional waterfall model, phases of iterative process are different and they mutually shift during the process with the different intensity and significance from iteration to iteration. BM is the first phase in each iteration. The most frequent problems appear as result of non harmonized notations and bad communication between software engineering and business engineering populations. Often business models are not adequate and not useful for system models development. However, business models based on UML BP eliminate all those problems. When we talk about the profile, we talk about defined set of standard language extensions which is built in UML and specialized for modeling in particular domain. There are several different UML profiles. One of them is intended for BM. BP [3] specializes some base classes of standard UML by introduction of business domain specific classes, like business use case (BUC), business use case model (BUCM), business object model (BOM), organization unit, work unit, business actor, worker, case worker, etc. Some authors consider business model as unique model [2], but according to BP, business model consists of two models: BUCM and BOM (Fig. 3).
Fig. 3. Business model defined by UML BP. B. Business use case model BUCM represents outside view of business system and describes business system and its relationships with the exterior systems through the BUCs. We consider that BUC is the business process, or some concrete function in business system offered to the exterior systems. Those exterior systems are called business actors. BUC is the sequence of actions, performed by workers in business system and by them business system makes some concrete and recognable value. BUCM contains descriptions of business actors and BUCs, and their interactions too. We represent that by BUC diagrams. BUCM includes the appropriate realization description of identified BUCs. BUC realization is documented by textual description and
graphical presentation [6]. Textual description considers specification of characteristics and activities of particular process and it's a good base for non-functional requirements capturing in the next phase of system development. For graphical presentation we can use activity diagrams or sequence diagrams [8].
The process nature (exactly defined sequence of actions) and similarity with traditional notations, refer to use activity diagrams. It is recommended to use high-level activity diagrams [6], where only the main activities (macroactivities), are shown without many details like responsibilities of workers and used objects. Additionally, swimlanes can be introduced to show activity distribution among the organization units or workgroups (recommended in complex business systems). C. Business object model BOM represents inside view of business system and in the completeness shows process, procedures, business worker's behaviour, used resources - business objects, and their relationships, that goals can be realized and expected results achieved. BOM usually includes detailed activity diagrams, some of interaction diagrams and object diagrams [6]. Complete process description in the business model is shown by detailed activity diagrams - high level activity diagrams completed by workers' responsibilities, used objects and object flows. Responsibility areas of involved workers are emphasized by swimlanes. All activities, objects and object-flows connected to particular worker are shown in the same lane, so we have as many swimlanes as workers who are involved in concrete BUC realization. In more general case, we have not only workers, but workgroups and organization units as well. Activity diagram is procedurally oriented and it is not appropriate for object-oriented (OO) IS development, so BOM also includes some of 00 interaction diagrams like: collaboration diagram or sequence diagram [7]. Collaboration diagram is very suitable to focus on structural component of process, but it isn't recommended in complex processes because of small or insufficient visibility. Sequence diagram offers possibilities to focus on temporal component of process, and it is very closed to activity diagram, so it is recommended to use it in BOM. In order to be possible easier class modeling in the next analysis and design phases of IS development, BOM includes business object diagram (BOD) also, which shows the static structure and relationships between objects. Thus, BOD can be used to show organizational structure of business system. BOM can include state charts too, especially in the case of more complicated transformations. D. Modeling methodology UML as standard modeling language prescribes notation and semantics, but doesn't prescribe modeling process. Several approaches are proposed [4], [6]. Process described in this paper consists of the next phases (Fig. 4): 1. BUC specification by BUC diagram, 2. textual description of BUC realization, 3. graphical presentation of BUC realization by high level activity diagram, 4. detailed description of realization by detailed activity
1264
diagram,
5. 00 interaction by sequence diagram, and 6. object diagram by BOD.
Next rules are valid during migration from BUCM: each BUC is the candidate for the system use case (UC), each business actor is possible system actor and each worker is possible system actor. During the transition of BOM, next rules are valid: each entity (worker or object) is possible system class and each message in sequence diagram is possible method of system class.
.Illklm
III. DYNAMIC ASPECT OF PROCESS
As we said, the IS lifecycle isn't an integral process, but process divided into more cycles, where each cycle deals with the new product generation. Development cycle consists of four phases: inception, elaboration, construction and transition. Each phase ends at the point where some great decision must be done, or some great goal(s) achieved [1]. Those points we call milestones.
Fig. 4. Proposed methodology based on UML profile. Identified BUCs, business actors, business workers and business objects can be used in transition from business models to initial system models. BUCM is transferred to the system use case model, and BOM is transferred to the system design model (Fig. 5).
Fig. 5. Transition from business models to system models.
A. Inception phase Inception phase requests from BM that makes adequate base for the specification of functional and non-functional system requirements. All exterior entities (business actors) and BUCs must be identified, and nature of their interactions high-level-described. This means that BUCM must be realized in completeness (Fig. 4). As we mentioned, realized BUCM can be used for efficient transition to initial system model. In this phase, each system UC must be identified, while only the most important must be described. This means that system UC model is about 10-20% complete. Output from this phase is the vision of base requirements, key characteristics and main constraints. Functional description of BUCs by high level activity diagrams is good base for definition of functional requirements in the goal system, while the textual description offer possibilities to specify nonfunctional requirements of the goal system. Inception phase can be done in single iteration. Often we call it preliminary iteration. However, in large scale business systems, like large industrial systems and institutions of public administration with great number of organization units, or heterogeneous subsystems, it is recommended to perform BM in several iterations - one subsystem per iteration. Dependent on the team dimension and experience, iterations can be parallely performed. In the large scale systems great number of heterogeneous BUCs can be identified, often more than several hundreds or thousand. In order to get better picture of whole system and solve the problem of visualisation complexity, all those BUCs can be grouped in higher level abstractions, like BUC package or BUC system. BUC package consists of some BUCs and appropriate relations, while BUC system can contain more BUC packages, single BUCs and appropriate relations. BUC systems aren't the organization units! Although usually system is structured that organization structure covers particular groups of activities, entire business system must be observed through the offered functions (UCs) to the actors. Sometimes, even some organization units can be actors, so the business actors are not always exclusively the exterior entities. Business actors are the entities to
1265
whom business system offers some valuable function, even they are interior or exterior entities. B. Elaboration phase The main goals of the elaboration phase are complete domain analysis, shaping goal architecture, developing dynamical plan and elimination of highest risk parts in particular project. All functional as well as non-functional requirements must be identified. That also includes other requirements not connected to any concrete use case. This is the most critical phase in IS development. Architecture, requirements and implementation plan must be enough stabile that offer possibilities for later successful detail changes. In this phase first real IS prototype must be realized in single or in more iteration, depends on particular domain, its greatness and complexity, as well as we deal with the new unknown or unusual project. This IS prototype must realize key UCs identified in the inception phase. It's better and more desirable to make several prototypes with less more critical situations and requirements. Demonstrations of these prototypes to the customer are obliged. At the end of elaboration phase UC model must be done with about 80% of completeness. This considers that great majority of identified UCs and actors are described. Thus, detailed plan for each iteration must be defined and developed. It is desirable that the preliminary user manual is written. The last goal of this phase is realized architecture of goal system. Evaluation criteria to end elaboration phase are: stable architecture of goal system, plan's correctness and feasibility and prototype efficiency in realization of the high-risk parts. The most important workflows in the elaboration phase are domain analysis and goal system design. These activities can be taken as an integral activity if there is no business process reengineering. However, often business processes in the real world are not optimised, with a lot of redundant and inefficient activities, so after the domain analysis where we develop "as is" model that describes present system state, business process reengineering follows where "to be" model will be developed, and after that, goal system design follows. In the elaboration phase, realized BOM is required from BM workflow. For all BUCs we must realize detailed activity diagrams as base for analysis of present business activities. If it is necessary, reengineering of "as is" model can be done and new to be model realized. Those "to be" activity diagrams are used to generate sequence diagrams and object diagrams, as we mentioned in static aspect of BM. Business model is here finished with more than 90%. Usually, elaboration phase is preformed through several iterations, especially in the case of large-scale business systems - subsystem by subsystem - one subsystem per iteration. Dependent on the team dimension and experience, iterations can be parallely performed. C. Construction phase Construction phase considers that all features of goal system are realized, integrated in system and checked in
details. Stress is put on resource management to optimise expenses and prize, quality and performances, etc. Many projects are enough large-scale so many activities can be parallel performed and in this manner we can improve and accelerate the realization of new product versions, but that can also augment the complexity of resource management and activity synchronization. At the end of this phase, product must be ready for the customer, actually "beta" version. This at least means that product is implemented on appropriate platform and also written documentation and user manual are finished. An evaluation criterion is stability of beta-version in real world. In the construction phase only some specific processes remain for BM workflow - processes with some errors detected during the past iterations. D. Transition phase Transition phase consider transfer from "labs" to real domain. Only fine tuning remains, like generating newer product versions and users training. This is the last phase in the IS development and it doesn't contain BM activities. IV. CONCLUSION
Although primary intended for visual modeling of software systems, thanks to BP, UML can be successfully used for BM, because very rich notation and semantics offer possibilities for all business domain analysis' aspects. UML based BM has especial importance if it's base for IS development. Then, notations for BM and system modeling are harmonized, and used concepts offer easy transfer business models to system UML models. In this paper, one approach to BM based on UML BP is presented. Both, static and dynamic aspect of BM in an I-I approach of IS development such as RUP, are described. Given approach is fully integrated in I-I model of software development, so thanks to the advantages of BM by UML BP, advantages of I-I approach are additionally augment, like: high risk parts are discovered earlier and their elimination is easier, business reengineering and system changes are easier to be realized, project team more and faster learns thanks to I-I approach and generally, level of quality is raised, too. REFERENCES [1] P. Kroll, P. Kruchten, The Rational Unified Process Made Easy. A Practitioner's Guide to the RUP, Addison-Wesley, 2003. [2] M. Penker, H. E. Eriksson, Business Modeling With UML: Business Patterns at Work, John Wiley & Sons, 2000. [3] Unified Modeling Language vl.4, OMG, 200 1. [4] D. Brdjanin, S. Maric, K. Bosnjak, "Poslovno modelovanje na bazi biznis profila UML-a", in Proc.47th Annual ETRAN Conference, Herceg Novi, 2003, p. 140-143. [5] D. Brdjanin, S. Maric, K. Bosnjak, "Poslovno modelovanje javne administracije na bazi biznis profila UML-a", in Proc. 10th Annual INFOFEST Conference, Budva, 2003, p. 204-212. [6] Business Modeling with the UML and Rational Suite AnalystStudio whitepaper, Rational Software, 2001. [7] G. Overgaard, B. Selic, C. Bock, Object Modeling with UML: Behavioral Modeling, OMG, 2000. [8] N. Pan-Wei (2002, Nov), "Effective Business Modeling with UML: Describing Business Use Cases and Realization". Rose Architect ezine. Available: http://therationaledge.com.
1266
