Template-based System Development using UML
by D.S.M.A.Liyanage (BSc (CIS) Hons’, AACS) email@example.com
At present, Information is a valuable resource as humans and for the business. If the Business needs to be successes in the present environment, Technology is very much important to every Business Organization. With the development in Technology, the Organizations require quick access to Data and accurate/reliable data for their business application. The Information technology has emerged as a solid foundation for it, by helping to store, retrieve and forward Data from one location to another almost instantly. As a result, Information Technology has combined with Business to support and provide Information handling process; meanwhile acquiring new Technology to the Organization, work will increase the Company image among the Business world. Computerization will eliminate many of the problems faced in manual system such as human errors, inefficiency and poor communication, less Data security and heaps of files maintenance. Also computerizing will give backup facilities for Data, better Security, easy access and update. Therefore, today Business Organizations are very much keen to transfer their manual System into computerized ones.
The modeling of information as required by the organization is the main process that Information Technology practitioners are doing, with the help of some modeling techniques. The Unified Process (UP) a well-known OO modeling technique, with some additional features is introduce in this article.
The Object Orientation has transforms our thinking and process of developing Software applications in a very rapid way for good. The Unified Process (UP) (an Object Oriented Technology based model) has made the technology applicable for our problem domains. The UP is very good in describing (Analysis) the problem domain and abstracting the required cases for development.
However, Object Modeling Technique (OMT) is more capable of describing the solution (Design) for a problem than the UP because of its models (the OMT is mainly base on models such as functional model, domain model, etc.).
Therefore, I am introducing a hybrid of both UP (for problem describing) with OMT (for solution describing); with some cross validation features, and implementing this as a template so it can be feather extended to match the requirements.
2. Problem Definition
We are developing a Use-Case in this section. The Use-Case contains Actors and there interests (role-played in the Use-Case process), the pre and post conditions (the states of the process that is before the executing of the case and after the execution), the steps of processing (basic flow of the Use-Case) and the extensions to the basic flow (additional and alternatives). The Structure of a Use-Case description
Use-Case: <Use-Case Name>
Primary Actor: <Actor>
Stakeholders and Interests:
-<Actor Name> : <Interests>
Post-Condition: <Post-Condition List> Trigger: <Triggering point 1 from extending Use-Case>, <Triggering point 2 from extending Use-Case> Extension Points: <Extension Point Name 1, Step number>, <Extension Point Name 2, Step number> Level: <Use-Case Level; Main | Top | Subfunction> Main Success Scenario: <Actor Name 1> <Actor Name 2> <Actor Name n> # <Description 1> # <Description 1>: Include <Including Use-Case name> # <Description 1> # <Description 1> # <Description 1> n. <Description n> Extensions: *a. <Extension Description 1 for all Scenario> *b. <Extension Description 2 for all Scenario> 2-3b. <Extension Description that is true for all 2nd point to 3bth point> 3a. <1st Extension Description of 3rd point> 3b. <2nd Extension Description of 3rd point> 4a. <1st Extension Description of 4th point>: Include <Including Use-Case name> The primary actor is identifying as the actor that is primary control of the Use-Case. And the trigger is used in the extended Use-Case (in abstract Use-Cases) this describes in what manner that Base Use-Case in extending this abstract Use-Case. The extension points are define in the extending Use-Case (in base Use-Cases), and this describes the step that is extending (scenario number) and the extension point (how it is extended). The level describes the extensibility of a Use-Case, either subfunctional (an additional Use-Case) or a Main/Top level Use-Case. In Main Success Scenario, we can write this either in the user level or as a full scenario. However, by writing the Use-Case in user level it is very easy to understand for the designer and for the requirement cross validation. When including a subfunctional Use-Case we are using the Include keyword, and then the Use-Case name. In the extensions, we are defining the alternate flows that are possible in the scenario. The ‘*’ numbering defines this alternate flow for the whole scenario. In addition to above structure (that is the main structure), following topics are also includable in the Use-Case Description. Special Requirements: -<List of technology variant requirements> Technology and Data Variation List: 3a. <List of Special technologies and standards that is use to fulfill the numbered point> Frequency of Occurrence: <The frequency of activation of this Use-Case> Open issues: -<List of external sources/activities that is affecting to this Use-Case> There are many types of Use-Cases, namely: # Concrete Use-Cases: Created with an interaction of an actor, and performs according the requirements of the actor. Most of the time the concrete Use-Cases will developed into elementary business process Use-Cases, that will uses or extend other subfunctional Use-Cases. # Abstract Use-Cases: Subfunctional Use-Case, that is part of another Use-Case. Moreover, it cannot act itself, but it is always part of another Scenario. # Base Use-Case: Use-Case that includes, extended or specialized by another Use-case is called a Base Use-Case. Usually these Use-Cases are Concrete. # Addition Use-Case: Use-Cases that is an inclusion, extension or specialization is called Addition Use-Cases. Usually these Use-Cases are Abstract.
The UML Use-Case Diagram
The figure 2.1 shows a sample UML Use-Case Diagram that shows inclusion, extension relationships.In the “Online purchase of items” Use-Case, we can see the extension points from the extended abstract Use-Cases (item advertising from Advertising items Use-Case and Order payment from Online payment Use-Case).
We are defining “Online purchase of items” Use-Case as follows;
The actor of this Use-Case is the Customer so,
Primary Actor: Customer
In addition, there are four actors in the Use-Case execution process (actors from the extending Use-Cases are also included) namely Customer, Government Tax agency, payment authorization service and Sales Company. The following describes only the customers’ interests (we are describing only as an example),
Stakeholders & interest:
-Customer : Buy goods & fast service with minimum effort, Nopurchases errors and no validation errors, aspurchases errors occurs, roll-back the transaction,and in time of validation errors roll-back thetransaction. When purchasing goods, the value willbe deducted from his/her credit-card. Wants proofof purchase to support returns.
When we are describing pre and post conditions, we must take into account that the pre conditions contains that is needed to fulfill the Use-Case scenario, and the post condition contains the after state of the scenario affected actors. Sample is shown below,
· Each customer is identified and authenticated.
· Each customer must have his/her own client access line.
· Purchases / sales are saved.
· Tax is correctly calculated.
· Accounting & inventory are updated.
· Receipt is generated.
· Payment authorization approvals are recorded.
This “Online purchase of items” also contains two extension points; it is represent as below,
Extension Points: Online payments, step 7. Advertising, step 2 to step 10
And the Scenario is describes as,
Main Success Scenario (Basic flow):
2. Customer sign-in to the site.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the external accounting system and Inventory system.
10. Customer sign-out from the site.
In addition, the Use-Case inclusion is describes in the extension points.
- a. At any time, system fails:
To support recovery & correct purchase calculation, ensure all transaction
sensitive states & events can be recovered from any steps of the scenario.
1. Systems Administrator restarts the System.
1a.Starts the DBMS and the Web Server.
2. System reconstructs prior state
2a.System detects anomalies in previous records System signals error
to the Systems Administrator, records the error, & enters a clean
state sends error report to the Manager; System starts a new process
when authorized by Systems Administrator or other authorized person.
1. System signs error & rejects access.
1a. Inform to Systems Administrator by information type event.
1b.Sendas an error report to DBMS log
2a-4. The logs-in process can be occurred in state 2a or in state 4 (selects
necessary items without logs-in).
8a. System sends information to external accounting system and Inventory system.
: Include Item management.
1. Records on Order database.
8b. System detects failure to communicate with external accounting system and
Inventory system. : Include Item management.
1. System sends a warning message to Systems Administrator.
2. System try to restart the service, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Show system unavailable state to Customers.
The special requirements of this Use-Case are describe as follows. These requirements are gathered in both customers (the targeting audience of the system) and companies(the stakeholder who will own the system after development) point of view.
* Browser with HTTP 1.1 support. * Browser must have scrolling capabilities. * Browser must have capabilities of handling cookies. * Internet connection (56K or grater than recommended).
The technology and data variation list describes special standards and techniques that will use in the Use-Case affecting data.
Technology & Data Variation List:
- . The item code must use a simple and readable coding scheme.
2a. Each customer must have his/her own unique account; the authentication
identifiers can’t be overlapped.
10a. The cookie time bomb will starts with beginning of the session.
The frequency of occurrence of the Use-Case contains,
Frequency of Occurrence:
Could be nearly continuous; But the web server has only a limited number of connections.
And the open issues contains what are the expecting problems when executing this Use-Case, the business analyst must find answers to these questions before designing the system.
-What are the Customer law variations?
-What are the tax laws in country?
-Explore the remote service recovery issues
-What customization is need for different business?
After we describe all the Use-Cases we must then design the interaction within the Use-Case and the interaction with other Use-Cases, we can easily done this by developing an activity diagram for whole system and developing system sequence diagrams for each Use-Case.
The development of an activity diagram for whole system, will give a clear-cut definition to the designer when to use parallel processing (threading etc.) and the interaction between Use-Cases. In addition, by drawing sequence diagrams other than collaboration diagrams, will give us internal structure (categorizing objects by process, interface, data and) of the Use-Case, with timely sequence (because we are drawing an activity for whole system and sequence for each Use-Case, we can reach the goals of drawing collaboration diagrams).
The UML Activity Diagram
The figure 2.2 shows sample Activity diagram for whole system.
Before we going to start the drawing of the sequence diagrams we must get an idea of what kind of objects are at the system (at the whole system), so now we can draw the domain model for the entire system by looking at the both Use-Case and the Activity diagrams. After the drawing of domain model, we can very easily draw the sequence diagram by using the Domain model with the Use-Case diagram.
The domain model describes an overall type interaction of the system. Moreover, this is the building block of the system design. The designer will extend the domain model with the help of sequence diagram to fulfill the Use-Cases; normally the domain model will extend by applying architectural design patterns (layering, data-access, etc.) with added security features and system specific types (if we are developing a web application we are including web specific components such as EJB, Servlets, XML Services, etc.).
The Domain Model
The figure 2.3 shows sample Domain Model for the above System.
As we discuss above this domain model defines the basic object structure exists in the problem domain, and when we are drawing the system sequence diagrams these must be presented according to the sequence that defines in the Use-Case and Activity diagram. And additional types can be added.
The UML Sequence Diagram
The figure 2.4 shows sample sequence diagram for the “Online purchase of items” Use-Case.
As we discuss above the sequence diagram which was drawn with the help of domain model and activity diagram and based on “Online purchase of items” Use-Case, is represented in the above figure. The above sequence is the base for the UML Class diagram, which will be draw after this with the help of domain model.
In the sequence diagram above, we also can structure the basic architectural design of the new system, with the applied patterns. As an example in the we are defining the UI, BLL, Model, etc. named instance components, so when designing the Type/Class diagram we can apply some layers for the above components and create more efficient and reliable design model (Class diagram).
3. Solution Development
The UML Class Diagram
The figure 3.1 shows a sample UML Class diagram with some layering.
Text Box: Figure 3.1
When we are drawing the UML Class diagram (design model), this is the most suitable time for apply the architectural and design patterns. In this sample I am showing how the layering is done (develop the domain models’ Account in to a well-designed manner).
The layering in this sample is going through in the process of figure 3.2,
Text Box: Figure 3.2
Finally, let us develop the component specification, in this model we are specifying how the type components physically arranged together and how they are accessing. One of the major benefits of development of system using components is the maintenance and usability. As an example, let us consider the following.
The UML Component Diagram
The figure 3.3 shows a sample UML Component diagram.
When we are applying software patches or service-packs, if the system is develop using components, and the bugs are in the encryption algorithms (in the Utility component), we can just update the Utility component rather than the whole system.
In the above article we have discuss how to use a hybrid version of UP and OMT for successful development of a system. The techniques (Use-Cases, Activity, Domain Model, Sequence, Class/Type and Component Model diagrams) used in above can be feather develop to suit a specific business requirements, so this modeling process can use as a template for other developments.
The techniques use above will model the system as figure 4.1.
Text Box: Figure 4.1
Larman C., 2002. Applying UML and Patterns. Delhi: Pearson Education, Inc,. ed: 2.
Object Management Group, 2005. Unified Modeling Language. Formal/05-07-04. ver: 2.0.
D.S.M.A.Liyanage (2007) Online Market Place for Thushara Super Super-Market. BSc Thesis, London Metropolitan University, UK.