January
2005 Issue: 34
January
2005 Issue: 34
Journal of Conceptual Modeling
www.inconcept.com/jcm
System
Level Use Case Structure of Domain-driven Process
To Develop Object-Oriented Software
ByShafeeq Ahmad and Vipin Saxena
and D.S. Kushwaha
Abstract
All standard object-oriented methods or processes being used to design large complex software systems, such as banking or telecommunications, provide a software system that certainly fulfils the requirements of functionality. Although getting all functional requirements of a system is important but that systems do not ensure other requirements such as modifiability and reusability. Furthermore the architecture is not explicitly described and is therefore difficult to comprehend. We present a domain-driven process to develop architecture of object-oriented software systems. This domain-driven process ensures other requirements such as modifiability and reusability along with functional requirements of the software systems. In order to define domain-driven process, we are applying domain characteristics and requirements of the system to architectural structure of the software. In this paper we present use cases to design architectural structure at system level to drive a domain-driven process.
To support the development of object-oriented systems of increasing size and complexity a number of methods and processes arose in the 1990s. Methodology was thereby introduced to object-orientation. The advent of object-oriented methods introduced structure on the object-oriented software development process.
The early methods like OMT [Rumbaugh 91], Booch [Booch 91][Booch 94], Designing Object-oriented Software [Wirfs-Brock 90], OOSE [Jacobson 92], defined terminology, notation and design artifacts. Many methods contributed significantly to the development of the field. A major contribution from OOSE was use cases. Use cases describe the interactions between systems and persons interacting with the system to be developed. Use cases can thereby be used to describe the functionality of the system.
Around 1995 the inventors of OMT, Booch and OOSE; James Rumbaugh, Grady Booch and Ivar Jacobson started working on a standardization of a common modeling language called UML [Rumbaugh 1998] [Booch 98], the Unified Modeling Language, which incorporated their work. In parallel to the UML definition, Jacobson, Booch, and Rumbaugh defined a general process for object-oriented software development called the Unified Process [Jacobson 99][Kruchten 98]. Another consortium of methods developers, consisting of Ian Graham, Brian Henderson-Sellers and Houman Younessi, have defined a process called OPEN [Graham 97]. Both processes are general processes, which leads software development from idea to product. The Unified Process is driven by use cases, iterations and architecture.
There has been rising consciousness about lack of architecture focus in object-oriented methods and processes during the last years. At the time being the focus seems to be on how to bring software architectures into these methods and processes. The Unified Process is an example of that concern, they claim that their process is architecture-centric, and they have a process phase, called the elaboration phase, dedicated for architecture development. Another of the latest development processes is Catalysis [D’Souza 98], which has its focus on component-based development in terms of developing coherent packages of software that are independently developed and delivered as a unit that can be composed unchanged, with other components to build something larger.
When we follow one of the standard object-oriented methods or processes for software development, we end up with a system that fulfills the requirements of functionality. The fulfillment of functionality is although important not sufficient. Today systems also have to be e.g. modifiable and reusable.
To obtain modifiable and reusable systems emphasize need to be put on architecture, because functionality can be implemented by an arbitrary architecture, but the quality of the architecture is influenced by the fulfillment of the non-functional requirements, such as e.g. modifiability and reusability, in the structures of a system.
By architecture we understand the structure or the structures of the software system, comprised by components and their properties and relationships. The software architecture is in general used to handle and communicate the complexity of software system structures. We find that the software architecture has not been explicitly described in the standard object-oriented methods and processes, and thus it has been difficult to comprehend and communicate.
We believe that one reason, for having insufficient focus on architecture, is related to the generality of the object-oriented methods and processes. They claim to be applicable in all domains. But different domains have different characteristics and requirements to fulfill and thereby use different architectural structures. We believe that a software architecture design process should be designed for a specific domain. The advantage of designing the process is that software architecture design becomes determined for the specific domain. We will delimit the process from aspects that are not important for the system, and we focus on architectural problems and solutions that are relevant. In this paper we present architectural structure by use cases for a specific domain i.e. banking.
Our process contains work-flows for how to handle the architectural structures at the different levels i.e. system level and application level. In this paper we define our process for system level software architecture.
2. System level software architecture design process:
The system level architecture comprises several integrated applications. The applications of the system provide the functionality, where the system architecture adds integrability between the applications. Integrability comprises the exchange of information and services between application modules. Integrability is about how multiple application modules, processes and processors collaborate to provide functionality.
The applications might be heterogeneous, running in different environments, using different data representations, and they can be distributed.
2.1 The use case structure:
Use cases describe the dynamics of the system. It can be discussed whether they are architectural components themselves, but they can be used as an instrument to find the architectural components in the other structures [Kruchten 95][Kruchten 98] [Jacobson 99]. They can also be used to assess that the requirements have been fulfilled as input to test cases [Jacobson 99]. A use case is a specified sequence of steps describing a use of the system. Use cases can be used to describe, design and test the functionality of the system [Jacobson 91][Lonvig 95]. But use cases can also be used to describe, design and test other requirements of the system, such as modifiability and integrability [Bass 98].
We define the use case structure, so that it covers all requirements of the system, both run-time and off-line requirements. It is then possible to assess if all the requirements have been fulfilled. We do not describe the assessment in this paper, but Ivar Jacobson et. al. [Jacobson 99] describes how to apply use cases as basis for test. Len Bass et. al. [Bass 98] also described how to use scenarios (=use cases) as basis for test of the requirements. Modifiability can be described, designed and tested by e.g. proposing specific changes to the system, security by proposing e.g. specific threat actions, and performance by proposing usage profiles that test resources. We can then say that use cases can be used to describe, design and test the non-functional requirements of the system.
We do not recommend that the domain characteristics are described in separate use cases, but more to use the domain characteristics as guidelines in the use cases describing the requirements. The reactive nature of the system is e.g. exposed in the use cases handling the functionality showing reactive interactions between actor and system. The reactive nature is also exposed in the use case covering the requirements of integrability between the actors and the system. We must assure that there are no conflicts between the domain characteristics and the use cases describing the requirements. Actors are persons or systems interacting with the system to design. We find that there exist two main types of actors in relation to use cases, when we decide to cover all requirements by use cases.
· Actors that interact with the system to get functionality and the other requirements related to run-time such as performance
· Actors that interact with the system to get off-line operations in the development environment such as modifiability.
These two types of actors reflect our categorization of the requirements into:
Ø requirements observable at execution,
Ø and requirements not observable at execution.
2.1.1 Architectural Process:
The process we define, to find the use cases and the architectural components of the other architectural structures, is an iterative process. We start with a handful of use cases based on the high-prioritized requirements of the system. We iterate, and take a new handful of use cases and so on.
Select a handful of use cases on the basis of the domain characteristics and critical requirements of the system:
When we want to design an architecture we should focus on the use cases that pose leverage on the architecture. This means use cases that capture the system’s critical requirements, the requirements that are most important, e.g. integrability, or the functionality used most frequently, or represent significant technical risk. These use cases are used to drive the process of creating the software architecture.
We start by identifying the use cases related to the run-time requirements. First we take the critical requirements of functionality, even though they can be fulfilled in an arbitrary architecture. The reason for starting with the functional requirements is that in any architecture, the components need to be assigned the right responsibilities and have the right facilities for coordinating with other components to perform the right functionality. We make the assumption that the critical requirements of a system can be described in around 20 use cases or less, depending on the size and complexity of the system. These main use cases can be used to drive the process of finding the system level architecture, because a use case is informally series of causally chained events typically spanning a set of cooperating processes spread across multiple processors in a system that represent some meaningful high-level operation. The techniques we use to describe the use cases are commonly known and described by Ivar Jacobson [Jacobson 92] and has the following outcome :
The use cases we have
identified are then used in the other architectural structures at the system
level. The use cases are used to identify:
3. Example:
For the propose of example we have taken the Bank Accounts and Transactions system. The Bank Accounts and Transactions system is to be built for the Big Bank Corporation. It must handle clients' bank accounts and the (standard) services on these accounts: deposit, withdraw, transfer, get balance.
The transactions are recorded, because at the end of each month, the system sends out account statements to all clients showing all transactions performed for their accounts during the last period; the system sends the statements to the printer from where a junior clerk posts them.
The system is accessed by the bank's customers only indirectly, i.e., either via a teller, an ATM, or the Internet. All transactions and queries are possible via a teller; all transactions and queries are possible except deposits via an ATM; and all except deposits and withdrawals via the Internet.
Opening an account can be performed only via a teller and the Internet; however, if a client opens an account via the Internet they must identify themselves with a teller to have their account activated.
Closing an account can only be performed by a teller, and it requires a final statement to be sent out to the client. The Bank offers various account types, which fall into two categories: savings and current. Savings accounts cannot be overdrawn. There can be a credit limit, subject to agreement by the bank, on current accounts; a current account cannot be overdrawn beyond this limit.
We define the use cases describing the requirements for ‘close account’ activity.
The actors performing are:
· Customer and Teller interact with the use cases describing run time requirements i.e. functionality, performance, dependability, distribution and scalability.
· Software developers and system maintainers interact with the use case describing off-line requirement i.e. modifiability, integrability, reusability and testability. The software developers and the system maintainers are the people developing and maintaining the software system.
We focus on use cases describing basic and important functionality of the ‘Close Account’ activity. Below we show an initial use case model for the ‘Close Account’ activity and we describe the selected use cases.
Fig. 3.1 The initial use case model of the Close Account activity
Use case “Close Account”:
System accepts Customer’s request and performs the following tasks:
1. Identifies him/herself
with Teller.
2. Teller informs System to close Customer's Account.
3. System closes Customer 's account and requests printer to print
Customer's final statement.
Extensions:
3a. System ascertains that
Customer still has funds on his/her account:
3a.1. Customer withdraws money from his/her account; use
case continues at step 3
3b. System ascertains that
Customer still owes money to the bank:
3b.1. System informs Teller; use case ends in failure.
Use case “Identifies Customer”:
The intention of the Customer is to identify him/herself to the System. Customers identify themselves with a Teller.
1. Customer identifies
him/herself with Teller in reference to an
account.
2. Teller validates identification with respect to account information.
Extensions:
2a. Teller requests System to
identify Customer, providing
identification details.
2a.1a. System validates identification of Customer, and
informs Teller ; the use case ends successfully.
2a.1b. System fails to identify Customer, and informs
Teller; use case ends in failure.
Use case “Check Account Balance”:
Customer does not interact with the System directly; instead, for this use case, System uses this use case in order to close Customer‘s account.
The Customer has already identified him/herself.
1. Teller requests System to provide the account balance, providing account details.
2. System informs Teller of the balance of Customer's account.
In view of above use cases required for “close account” activity, we can attach run-time requirement i.e. functionality, performance and scalability and off-line requirement i.e. modifiability, integrability, reusability and testability. Performance requirements can be attached to the use cases covering functionality, For example that the Teller should get back Customer’s balance with in 10 seconds after his/her initiation.
The requirement of scalability is to handle for instance a variable number of Customers and Tellers.
The off-line requirements can also be specified as use cases. The actors are here developers and maintainers of the software.
A use case for integrability
can for example be:
·
Operate
and interface with different components, both new software and hardware
Use case for modifiability can for example:
·
Extend
the functionality and handle upgrades of hardware and software
·
Develop a
subset of the system
4. Conclusions And Results:
We have in the use case structure demonstrated how to describe both the functional and the non-functional requirements as use cases. These use cases are used in the other structures to identify the components: modules in the module structure, processes in the process structure and processors in the physical structure.
References:
[Booch 94] Booch,
Grady; Object-oriented Analysis and
Design with Applications; Addison-Wesley, 1994.
[Booch 98] Booch,
Grady, James Rumbaugh, Ivar Jacobson; The
Unified Modeling Language User Guide; Addison-
Wesley, 999.
[D’Souza
98] D’Souza, Desmond, Alan Cameron Wills; Objects,
Components, and Frameworks with UML; Addison-
Wesley, 1998.
[Jackson
95] Jackson, Michael; Software Requirements &
Specifications; Addison-Wesley, 1995.
[Jacobson
92] Jacobson, Ivar, Magnus Christerson, Patrick Jonsson,
Gunnar Overgaard; Object-Oriented Software Engineering; Addison-Wesley,
1992.
[Jacobson 94] Jacobson, Ivar, Maria Ericsson, Agneta Jacobson; The Object Advantage; Addison-Wesley, 1994.
[Jacobson 97] Jacobson, Ivar, Martin Griss, Patrik Jonsson; Software Reuse; Addison-Wesley, 1997.
[Jacobson
99] Jacobson, Ivar, Grady Booch, James Rumbaugh; The
Unified Software Development Process; Addison-Wesley, 1999.
[Kruchten
95] Kruchten, Philippe; The 4+1 view model of software
architecture; IEEE Software vol. 12, no. 6, p42-50,
November 1995.
[Kruchten 98] Kruchten,
Philippe; The Rational Unified Process: An
Introduction; Addison-Wesley, 1998.
[Rumbaugh 91] Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenson; Object-oriented Modeling and Design; Printice Hall, 1991.
[Rumbaugh
98] Rumbaugh, James; The Unified Modeling Language
Referenc
Shafeeq
Ahmad
Assistant Professor & Head, Dept. of Computer Applications
Azad Institute of Engg. & Tech., Lucknow, India
email : ahmad_shafeeq@rediffmail.com
Vipin
Saxena
Co-ordinator, Dept. of Computer Science
Babasaheb Bhimrao Ambedkar University, Lucknow, India
email : vsax1@rediffmail.com
D.S.
Kushwaha
Systems Manager, Institute of Engg. & Tech., Lucknow, India
email : kushwaha_ds@rediffmail.com
© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement. ISSN: 1533-3825