· Introduction
· Mechanism of Object-oriented Approach
· Unified Modeling Language
· Analysis Process
· Use-case Modeling
· Class Modeling
· Conclusion
· References
 

Introduction

There have been basically 3 approaches in information system development area: process-oriented, data-oriented and object-oriented approaches. As information technology (both hardware and software) has been advancing, people have moved from the earliest process-oriented approach to data-oriented approach and now begun to adopt the latest object-oriented analysis methodology.

Unlike its two predecessors that focus either on process or data, the object-oriented approach combines data and processes (called methods) into single entities called objects. Objects usually correspond to the real things an information system deals with, such as customers, suppliers, contracts, and rental agreements. Object-oriented model is able to thoroughly represent complex relationships and to represent data and data processing with a consistent notation, which allows an easier blending of analysis and design in an evolutionary process. The goal of object-oriented approach is to make system elements more reusable, thus improving system quality and the productivity of systems analysis and design (Hoffer et al. 2002). Though systems analysis is closed associated with design, this paper tries to focus on analysis part of the methodology.
 

Mechanism of Object-oriented Approach

The principals of objects, encapsulation, inheritance, and polymorphism are the foundation for object-oriented systems development. To understand and express the essential and interesting features of an application in the complex real world, an object-oriented model is built around objects. An object encapsulates both data and behavior, implying that analysts can use the object-oriented approach for both data modeling and process modeling.

Specific objects in a system can inherit characteristics from the global instance of an object. For example, many types of objects may have a name and a creation date. Specific objects can inherit these global characteristics from parent objects that include only global characteristics. Objects can inherit characteristics from more than one parent object. Inheritance attempts to avoid the redundant definition of similar characteristics that can be embodied at higher levels in the system (Cackowski 2000).

By a concept called polymorphism, functionality that is conceptually similar among differing objects is extracted to a global level. This process limits the production of parallel functionality and streamlines the information interface. Polymorphism directs the specification writer to understand the functionality of a process and make it available to any object that requires a similar instance of functionality (Cackowski 2000).
 

Unified Modeling Language

The Unified Modeling Language (UML) is an object-oriented language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling (UML Document Set, 2001). The UML was developed by Rational Software and its partners. It is the successor to the modeling languages found in the Booch (Booch 1994), OOSE/Jacobson, OMT and other methods.

By offering a common blueprinting language, UML relieves developers of the proprietary ties that are so common in this industry. Major vendors including IBM, Microsoft, and Oracle are brought together under the UML umbrella. And because UML uses simple, intuitive notation, nonprogrammers can also understand UML models. In fact, many of the language's supporters claim that UML's simplicity is its chief benefit. If developers, customers, and implementers can all understand a UML diagram, they are more likely to agree on the intended functionality, thereby improving their chances of creating an application that truly solves a business problem (Apicella 2000).

The UML, a visual modeling language, is not intended to be a visual programming language. The UML notation is useful for graphically depicting object-oriented analysis and design models. It not only allows you to specify the requirements of a system and capture the design decisions, but it also promotes communication among key persons involved in the development effort (Hoffer et al. 2002). The emphasis in modeling should be on analysis and design, focusing on front-end conceptual issues, rather than back-end implementation issues, which unnecessarily restrict design choices (Rumbaugh et al. 1991).
 

Analysis Process

In the analysis phase, a model of the real-world application is developed showing its important properties. It abstracts concepts from the application domain and describes what the intended system must do, rather than how it will be done.

Most proponents of object-oriented analysis (OOA) claim that the use of object-oriented concepts in the analysis phase (i.e., OOA) increases the understanding of problem domains, that OOA promotes a smooth transition from the analysis phase to the design phase, and that OOA provides a more natural way of organizing specifications (Coad & Yourdon, 1991).

Extant object-oriented approaches can be classified into three categories (Monarchi & Puhr, 1992): (1) combinative approaches use different modeling techniques in different stages of the system development process; (2) adaptive approaches apply existing techniques (e.g., data-flow diagram and entity-relationship approach) in object-oriented ways to analyze the problem domain; and (3) pure approaches adopt an object-oriented perspective in systems analysis and design.

Despite various ways to do modeling, this paper focuses on use-case modeling and class modeling to explore how system analysis are conducted under different methods.
 

Use-case Modeling

First adopted by Jacobson et al. (1992), use-case modeling is developed in the analysis phase of the object-oriented system development life cycle. Use-case modeling is done in the early stages of system development to help developers gain a clear understanding of the functional requirement of the system, without worrying about how those requirements will be implemented.

A use-case is a representation of a discrete set of work performed by a use (or another system) using the operational system (). A use-case model consists of actors and use cases. An actor is an external entity that interacts with the system and a use case represents a sequence of related actions initiated by an actor to accomplish a specific goal (Hoffer et al. 2002).

For identifying use cases, Jacobson et al. (1992) recommend to ask the following questions:

· What are the main tasks performed by each actor?
· Will the actor read or update any information in the system?
· Will the actor have to inform the system about changes outside the system?
· Does the actor have to be informed about unexpected changes?

In UML, a use-case model is depicted in a use-case diagram that contains the use cases and actors for a system. Begin working with the UML by modeling all scenarios in the system or business with Use Case diagrams. Describe the system in terms of actors, which are external agents that request a service from the system, and Use Cases. Each Use Case can be defined simply by a textual statement that describes the scenario, or via other definitions, such as the sequence of steps that are performed within the scenario, or the pre- and post-conditions of the scenario (Popking 2001).

A use-case diagram for a hotel reservations system is shown in Exhibit 1. An actor is shown using a stickman symbol with its name below. There are two actors outside the box: manager and receptionist. Inside the box are 12 use cases – run management reports, cancel unconfirmed reservation, cancel reservation, check in guest, check out guest, etc.

Use-cases are shown as ellipses with their names inside and are performed by the actors outside the system. A use-case is always initiated by an actor. For example, Check In Guest is initiated by Receptionist.

A use-case may interact with other use-cases. Some of these relationships include extend and use and are reflected by single hollow arrow lines. For instance, Cancel Reservation use case uses information from Customer Requests Cancellation use case or Cancel Unconfirmed Reservation use case to finalize the actual cancellation of reservations.

While a use-case diagram shows all the use cases in the system, it does not describe how those use cases are carried out by the actors. The contents of a use case are normally described in plain text. While describing a use case, you should focus on its external behavior, that is, how is interacts with the actors, rather than how the use case is performed inside the system (Eriksson and Penker, 1998).

Also called system usage modeling, a use case modeling, at requirements analysis stage, consists of a Use Case Diagram plus a set of descriptions as well as illustrations of prototype screens.

One of the benefits of use-case or system usage modeling is its simplicity. The strength of the technique is in its non-technical simplicity, which allows users to participate in a way that is seldom possible using the abstractions of Class Modeling alone. It also helps the analyst get to grip with specific user needs before analyzing the internal mechanics of a system. Use cases also fit particularly well within an evolutionary and incremental process in that they provide a basis for early prototyping and readily identifiable units for incremental delivery. They also provide a means of traceability for functional requirements upstream in the process and for constructing test plans downstream in the process. It is no accident therefore that use cases have become such a popular technique (Artisan 2001). In summary, (Artisan 2001) provides a complete list of the steps in system usage modeling as follows:

· Identify the actors.
· Identify the use cases.
· Create a Use Case Diagram.
· Describe the use cases.
· Complete the use case descriptions.
 

Class Modeling

There are many new terms in object-oriented approach. Some have already been introduced above. An object is the most fundamental element in OO approach, which has a well-defined role in the application domain, and has state, behavior, and identity. A class is a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.

Object modeling, or class modeling is the key activity in object-oriented development. If the use cases contain errors, then all is not lost. If the class model contains errors then all may well be lost. The quality of the resulting system in object-oriented development is essentially a reflection of the quality of the class model. This is because the class model sets the underlying foundation upon which objects will be put to work. A quality class model should provide a flexible foundation upon which systems can be assembled in component-like fashion. A poor class model results in a shaky foundation upon which systems will grind to a halt and buckle under the threat of change (Artisan 2001).

Each of the diagrams used in UML lets you see a business process from a different angle. Business users, for example, can view use case diagrams to see the business scenario overview and understand who's doing what, while developers can use class and object diagrams to get accurate descriptions of how to build those components into their code. The class and object diagrams are so detailed, describing elements such as interfaces and attributes, that translating UML notation into actual programming code is a virtual no-brainer (Apicella 2000).

In UML, a class is represented by a rectangle with three compartments separated by horizontal lines, which hold, from top to bottom, class name, the list of attributes, and the list of operations. A class of person is shown in Exhibit 2.

A class diagram allows you to document how the class relates to other classes. The class diagram doesn't fix the actual implementation. The actual code might not be a direct translation of the diagram. However the functionality of the code will remain the same. In the Exhibit 3 you can observe the following:
· Class A is a class that has some attributes (variable) and functions (function).
· Class A is the parent class of Sub-Class
· Class A is associated with Class B. In this case only 1 Class B is associated with possibly multiple versions of Class A. The association is named something. Depending on the type of UML diagrams you are using, something can be implemented using a variable or by something else.
· Class T is a template class.
· Class B is an instance of Class T where the parameter T is bound to int.
· General is an associate class that can add attributes (or function) to the association between Class A and Class B. In the present case, it adds the variable period.
 
 

The above diagram shows the logical relationship between the components. It doesn't mean that a C++ class would be implemented using all the 5 classes represented here. Short cuts can be taken. However, the logical structure must remain the same. For example, you can move period outside of the General class and inside the Sub-Class. But the logic of the association remains the same.

There are four types of operations: constructor, query, update, and scope operations. A query operation accesses the state of an object but does not alter the state (Fowler 2000).

Associations usually connect two different classes. But they can also be drawn from one class to itself. The association relationship may be one (unary), two (binary), three (ternary), or higher (n-ray) (Hoffer et al. 2002).

In the object-oriented approach, you can abstract the common features (attributes and operations) among multiple classes, as well as the relationships they participate in, into a more general class. This is known as generalization. There are also classifications of abstract and concrete classes.

Conclusion

In the nearly four years since the Object Management Group (OMG) adopted the Unified Modeling Language (UML) in 1997, it has quickly established itself as the standard language for specifying software systems. From domains ranging from healthcare and finance to telecommunications and aerospace, UML is the common choice for defining software architectures. The modeling language has become so popular among developers that it is difficult to find a software project with more than ten developers who don’t use UML in some way to specify part of their architecture (Sparks 2000).

The association of model and various vendor CASE tools thus provides all the necessary means to master software development at model level. Automation provided by the tool must, however, guarantee that overall consistency is maintained and that all development is monitored (Softeam 2000).

There are total nine types of UML diagrams: class, object, use case, sequence, collaboration, state-chart, activity, component, and deployment (Unimodeler 2001). While a use-case diagram shows the interaction between external actors and actions performed within a system, a class diagram describes the static structure of objects in the problem domain. The other seven diagrams all provide differing perspectives on systems and are also useful in system analysis and design. It should be noted that different vendor products support different models. When to use which diagram remains to be a further research topic.

References:
 

1.	Adaptive Arts. http://www.adaptive-arts.com/prod_so_uml.htm#AttributesOperations, last updated unknown, accessed on November 03, 2001
2.	Apicella, Mario. UML simplifies project notation. InfoWorld, Framingham; Mar 27, 2000; Vol. 22, Iss. 13; pg. 69, 2 pgs
3.	Artisan Software, http://www.artisansw.com/mentor/start.htm Last updated unknown, Accessed on November 11, 2001
4.	Booch, G. 1994. Object-Oriented Analysis and Design with Applications. 2nd.ed. Redwood City, CA: Benjamin/Cummings
5.	Cackowski, David. Object analysis in organizational design: A solution for matrix organizations; Project Management Journal, Sylva; Sep 2000; Vol. 31, Iss. 3; pg. 44, 8 pgs
6.	Coad, R, and Yourdon, E. Object-oriented Design, (2nd Edition), Englewood Cliffs, NJ: Yourdon Press. 1991.
7.	Eriksson, H., and Penker, M. 1998. UML Toolkit, New York: John Wiley.
8.	Foller, M. 2000. UML Distilled: A Brief Guide to the Object Modeling Language. 2nd. Ed. Reading, MA: Addison-Wesley.
9.	Gentleware, http://www.gentleware.com/products/documentation/PoseidonUsersGuide.html#N40038E, last updated unknown, accessed on November 11, 2001
10.	Hoffer, Jeffrey A.; George, Joey F.; Valacich, Joseph S. Modern Systems Analysis & Design, 3rd edition. Upper Saddle River, N.J.: Prentice Hall, 2002.
11.	Jacobson, I. M., Christerson, P. Jonsson, and G. Overgaard. 1992. Object-Oriented Software Engineering: A Use-Case Driven Approach. Reading, MA: Addison-Wesley.
12.	Monarchi, D.E., and Puhr, G.I. (1992). A Research Typology for Object-Oriented Analysis and Design. Communications of the ACM, Vol. 35, No. 9, pp. 35-47.
13.	Philippe, Lavoie. http://yukon.genie.uottawa.ca/~lavoie/software/uml/ Last modified: Jan 18, 1999, accessed on November 08, 2001
14.	Popking Software, http://www.popkin.com/products/sa2001/object/component.htm#UML%20beginning Last updated unknown, accessed on Nov. 02, 2001.
15.	Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. 1991. Object-Oriented Modeling and Design. Englewoor Cliffs, NJ: Prentice-Hall
16.	Softeam, 2000. http://www.softeam.org/pdf/us/model_driven.pdf, accessed on November 11, 2001
17.	Sparks, Geoffrey. 2000.  http://www.sparxsystems.com.au/WhitePapers/The_Use_Case_Model.pdf, accessed on November 11, 2001
18.	Telelogic, http://www.telelogic.com/publications/uml_models/, last updated unknown, accessed on November 11, 2001
19.	UML Document Set, http://www.omg.org/, Last updated on June 25, 2001. Accessed on Nov. 10, 2001.
20.	Unimodeler, http://www.unimodeler.com/, last updated on 1/13/2001, accessed on November 11, 2001