John Yu s1039991

MSIS 488 Fall 2002

Over the past decade, the systems development lifecycle (SDLC) has adopted several methodologies, one of which happens to be object-oriented analysis (OOA). OOA came into being through an evolutionary process over the last 40 years in object modeling [19]. The concept of object modeling took shape as a move away from procedural based approaches in systems analysis to a more intuitive and integrated approach in classifying objects with functions and attributes. Where structured analysis has limitations, proponents of OOA claim those limitations are eliminated by focusing on objects in modeling the real world. Some industry critics have lamented that structured analysis is limited to analyzing data flow and hence leaves little in terms of providing an integrated view of a complete system whereas OOA provides a more realistic and simplified approach to modeling [16]. Increasingly complex business systems have brought about an "impedance mismatch" between users and developers [3]. These are situations where users have difficulty expressing precisely their software system requirements. And analysts and developers often grapple with the problem of defining what that user really needs. The culmination of an object-oriented perspective has given some systems analysts and developers a different approach in meeting end-users goals. One inherent advantage of OOA is that it offers stakeholders the flexibility to meet the constant changes of user requirements, or at least make a more seamless transition towards the desired objective [14]. Before going into a laundry list of why object-oriented methodologies have gained popularity, one would need to understand the concept of objects and where its inception and development currently stands.

According to Grady Booch, one of the first pioneers in object-oriented technologies, OOA tries to provide a common language in which developers and end-users can converge upon and seek a better understanding of each other’s domain. Specifically, Booch states "In OOA, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain…" [2] OOA is also an iterative process in defining the behavior and information of the system. [8]

What exactly is an object or a class for that matter? Objects, in their most abstract form, can be tangible things like a telephone, employee, or compass or they can be intangible things like a bank account or service department. By identifying objects one can classify similar and dissimilar attributes into classes. However, objects also exhibit behavior in which further defines it from its counterparts. Behavior in this case means how an object reacts when acted upon. A simple illustration to define how these objects work: a loan processor may ask a credit agent to look up an applicant’s credit rating. The credit agent will dutifully process this request and return the desired information back to the loan processor. This scenario can be framed within a software system where the loan processor and credit agent are just software components rather than people. In this case, the loan processor has sent a message to the credit agent. Upon receiving this request the credit agent will perform its own processes to retrieve the applicant’s credit rating and send this information to the loan processor. From the loan processor’s standpoint, he/she or it does not care how the credit agent processed this request. As long as the loan processor receives an answer to its request, everything is fine.

As mentioned earlier, objects can be subdivided into two components: attributes and functions. However, encapsulation, inheritance, and polymorphism are the three key concepts that underlie object modeling.

Objects encapsulate their respective data (attributes about itself) and methods (functions or behaviors). This arrangement of isolating and hiding the object’s internal processes relieves the requestor from having to craft on ‘how’ the request should be made. Instead, the requestor can simply declare ‘what’ should be done [4, 18].

Inheritance is another important concept that enhances object modeling towards further extensibility. Inheritance captures similarities between objects and therefore groups them into classes while at the same time creating a hierarchy among classes. A class, in simple terms, abstracts common objects and serves as a blueprint. Obviously, this idea is not new to human thinking since all humans, as early as toddlers, have intuitively grouped physical objects together whether they were conscious of it or not. From a more formal and historical perspective, Carl Linnaeus, the father of taxonomy applied his classification scheme to make order of the botanical world. Take plants for example. Plants have similarities that distinguish it from animals. However, within the plant class, one can delineate between trees, shrubs, and grass, each possessing their unique attributes. However, these plants have underlying common attributes like cell walls, stems, root systems, etc. Back to a business perspective, a loan class possesses a basic set of attributes that describe all loans. Specialty loans (i.e. equity loans, educational loans) can inherit these common attributes from its parent class and add unique attributes to distinguish itself from its parent class and other specialty loan classes. This gives analysts and developers enormous convenience in terms of reusability [15]. Re-inventing the wheel becomes less laborious when crafting a new sub-class due to inheritance [8].

The last key concept in OO technology involves the ability for a common definition to refer to different possible implementations [1]. In other words, a polymorphic operation allows a particular method to be chosen depending on the type of object making the request and thus increasing the object’s processing flexibility. In the loan-processing example, the credit agent can field requests from different loan processors. Each of these loan processors may pass in slightly different information to the credit agent, due in part to the type of loan being requested. The credit agent object will handle each request accordingly yet produce the same result. All objects within a class can have the same operations from a behavioral standpoint [10].

Many proponents of OOA claim that this approach brings about a more seamless transition from analysis to design and implementation due to the fact that each phase does not require analysts to develop a whole new representation. It is common knowledge that user requirements often change during software systems development. This is due to the fact that ongoing developments will alter the rules of the problem itself. OOA is an iterative process so as more iterations occur, users develop a better understanding of the system and in turn are better able to identify and articulate their real needs- another benefit in giving users and analysts to tackle complex system problems. [9]

The transitions between analysis, development, and implementation translates into three general areas of OO technologies: OOA, Object-Oriented Development, and Object-Oriented Programming. The products of OOA serve as the models from which one may start the OO design. Next, OOD can then be used as the framework for implementation via object-oriented programming (i.e. Java, Smalltalk, C++, PowerBuilder) [18]. These transitions are made possible by adhering to consistent notation and semantics throughout the systems development process. [6] This avoids the complications of having to develop a whole new representation between analysis, design, and implementation.

Since the early 80’s, there has been a plethora of object-oriented methodologies making a claim in the SDLC arena. [7] From Booch, Fusion, OOSE to Z++, this wide assortment has created some confusion and limited progress in terms of standards and notation. However, one modeling language that is making headway and gaining in popularity is the Unified Modeling Language (UML), which was formally adopted by the Object Management Group (OMG) in late 1997. According to OMG, modeling a system can be done on "just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML." [21] In addition, UML has garnered widespread industry support due to the fact that it is methodology-independent.

UML is a graphical language, which tries to communicate to the user by visualizing each component as an object with inherent properties within a software system. [5] Some have argued that using the right OOA methodology is critical especially when dealing with business applications in a client/server environment. Others however believe OOA is just another tool to add to the analyst’s toolbelt and should not replace other tools such as data flow, process flow, and state transition diagrams [17]. However, some of these concerns have subsided to a certain degree with the introduction of Java during the mid-90s and the standardization of UML in 1997. According to Alhir, the UML provides several different perspectives, otherwise known as architectural focus, to interested parties. These are 1) the user model; which are expressed through use-case diagrams, 2) the structural model; expressed through class and object diagrams, 3) the behavioral model; which possesses the dynamic and process-oriented views of a system and are depicted via sequence, collaboration, state, and activity diagrams, 4) the implementation view; which encompasses the structural and behavioral models and is depicted through component diagrams, and finally 5) the environmental model; which lays out the physical aspects of the structural and behavioral views through deployment diagrams. He also mentions that other diagrams may be included as stakeholders see fit to address certain issues unique to their own environment. [12] In deciding what diagrams to use, Alhir suggests one to "consider the question or questions the communication is addressing, and what diagram or set of diagrams most effectively communicate the response." [12]

Since UML has become the de facto modeling language in OOAD many vendors and IT shops have built proprietary tools to support UML’s specifications. However, as the extensibility and leverage of UML grows, some industry observers have expressed concerns of UML burgeoning complexity. As Kobryn succinctly puts it "UML could devolve into a Babelian mix of home-brewed notations with unintelligible semantics." [20]

UML consists of nine components, which allow stakeholders different architectural focuses through different types of diagrams: 1) Class diagrams, 2) Object diagrams, 3) Use-case diagrams, 4) Activity diagrams, 5) Component diagrams, 6) Deployment diagrams, 7) Sequence diagrams, 8) Collaboration diagrams, and 9) State-chart diagrams. [12, 13] Of the nine components in UML, the Use-case, Class, and Object diagrams are best suited in the analysis phase of an OO SDLC. [6]

The use-case method was developed by Ivar Jacobson during the 80’s and subsequently joined Booch and Rumbaugh to formulate UML. The use-case component basically documents system requirements. The process focuses on what an existing system is doing. Therefore, how the system functions is not addressed under this view. A use-case diagram consists of a rectangle representing the system. Within the system are relevant use-case ellipses that identify a particular function. Actors, users that act upon the use-cases and carry out those functions, are represented externally from the system. Actors can be individuals or things, such as a software component. Mark Collins depicts a simple banking system through a use-case diagram in this figure [22].

The other relevant components to analysis in UML are class and object diagrams. Class diagrams simply describe the type of objects within the system. They essentially are blueprints from which users can abstract a model or representation from the real world. From these classes, objects can be created (also referred to as instantiation) which share common attributes yet maintain some uniqueness from other objects created from the same class. Actors need to be defined by their roles rather then by a literal description of a job title or of a person [5, 11].

Users of use-case modeling can also graphically describe three key relationships between actors and use-cases. The first relationship, include, occurs when a behavior is similar across more than one use case and therefore redundant if represented in an iterative fashion. To simplify the diagram from redundant clutter, that particular use-case can be listed just once within the system and use-cases needing to utilize this particular behavior/function can refer to it via a dashed line along with the word ‘include’ in angled brackets. For example, two types of loans, one being a home mortgage loan and the other being a home equity loan, may call out (include) another use-case called home assessment in order for each type of loan to get its job done [6]. The second relationship is referred to as ‘use-case generalization.’ [5] This is applicable when a user is faced with alternative scenarios. In this instance, there are two use-cases; the base use-case and a specialized use-case, which will automatically override the base use-case if an alternate path is required. In the loan-processing example, an actor applies for a loan and several outcomes may result: approval for the requested full amount, partial amount, or rejection. In this case, full approval would be viewed as the base use-case while everything else is the specialized use-case that can override the base use-case. Finally, the third relationship is known as the ‘extend’ relationship. Like the second relationship, ‘extend’ is a variation on normal behavior. According to Fowler, this extending use-case will add more behaviors on top of what is available from the base use-case. The notation for this is declaring ‘extension points’, like the ‘include’ dashed lines, pointing towards that additional behavior found in a particular use-case. This can be illustrated in e-commerce websites like Amazon.com. First-time and infrequent customers to Amazon.com do not have a speedy checkout hyperlink available during their visits. Regular customers, however, due to their prior transaction history can invoke the speedy checkout link since Amazon.com already has the patron’s payment and shipping info stored in a database. Schematically speaking, on a diagram this would look like this:

The OOA approach is a departure from its predecessors since it takes the novel idea of viewing almost everything as an object. In addition, these objects contain processes and data about themselves; something those older analysis methods treated as separate. The past decade has allowed systems analysts, software engineers, and business analyst to utilize various OOA methodologies. Drawbacks to this became apparent when standardization seemed elusive and not everyone could agree on syntax and notation despite a consensus on the OO concept. However, in recent years, sanctioning bodies like OMG have set forth detailed specifications in OO modeling techniques, namely UML. In addition, the evolution of 4GLs like Java is well suited in complementing OO projects. The future of OOA is promising, however, as pointed out earlier it may not be the best solution for every project or business problem.

References

1. Baudoin, Claude, Hollowell, G. Realizing the Object-Oriented Lifecycle. Prentice-Hall, Inc. Upper Saddle River, NJ. 1996.

2. Booch, Grady. Object-Oriented Analysis and Design. The Benjamin/Cummings Publishing Company, Inc. Redwood City, CA. 1991.

3. Booch, Grady. Object-Oriented Analysis and Design with Applications, 2^nd ed. The Benjamin/Cummings Publishing Company, Inc. Redwood City, CA. 1994.

4. Coad, Peter, Yourdon, E. Object-Oriented Analysis, 2^nd ed. Prentice-Hall, Inc. Englewood Cliffs, NJ. 1991.

5. Fowler, Martin. UML Distilled: Applying the Standard Object Modeling Languages. Addison-Wesley Longman Inc. 1997.

6. Hoffer, Jeffery, George, J., Valacich, J. Modern Systems Analysis & Design, 3^rd ed. Prentice-Hall, Inc. Upper Saddle River, NJ. 2002.

7. Hutt, Andrew T.F. Object Analysis and Design Description of Methods. J. Wiley & Sons, New York, NY. 1994.

8. Jacobson, I., M., Christerson, P. Jonsson, G. Overgaard. Object-Oriented Software Engineering: A Use-Case Driven Approach. Addison-Wesley, Reading, MA. 1992.

9. Mylopoulos, John, Chung, L., Yu, E. "From Object-Oriented to Goal-Oriented Requirements Analysis." Communications of the ACM. January 1999 42(1): 31-37.

10. Rumbaugh, James, Blaha, M., William, P., Frederick, E., William, L. Object-Oriented Modeling and Design. Prentice-Hall, Inc. Englewood Cliffs, NJ. 1991.

11. The Unified Modeling Language: UML ‘98: beyond the notation: First International Workshop, Mulhouse, France, June 3-4, 1998: selected papers / Jean Bézivin, Pierre-Alain Muller (eds.). New York, Springer. 1999.

Online References

12. Alhir, Sinan Si. "Understanding the Unified Modeling Language (UML)." http://home.earthlink.net/~salhir/UnderstandingTheUML.PDF April 1999, Martinig & Associates. Accessed 11/5/02.

13. Bhagwat, Amit. Cetus-Links. "Architecture and Design: Unified Modeling Language (UML)." http://www.cetus-links.org/oo_uml.html Last updated: 7/5/02. Accessed: 10/31/02

14. Biggs, Peter. University of Durham. "A Survey of Object-Oriented Methods." students.cs.byu.edu/~pbiggs/survey.html. Last updated: 3/22/99. Accessed: 10/22/02.

15. Bray, Mike. Carnegie Mellon Software Engineering Institute. "Object Oriented Analysis Software Technology Review." http://www.sei.cmu.edu/str/descriptions/ooanalysis_body.html Last updated: 9/22/00. Accessed: 10/27/02.

16. First Step Communications. "Object-Oriented Computing - What's the Big Deal?" www.firststep.com.au/education/solid_ground/oo.html. Last updated: unknown. Accessed: 11/2/02.

17. Gora, Michael. DBMS. "Object-Oriented Analysis and Design." www.dbmsmag.com/9606d15.html. Last update: 5/96. Accessed: 11/1/02.

18. Hathaway, Robert J. "Object FAQ." Object Magazine Online. www.cyberdyne-object-sys.com/oofaq2/ Last updated: 12/27/97. Accessed: 11/2/02.

19. Holmevik, Jan. "The History of Simula." java.sun.com/people/jag/SimulaHistory.html. Last Updated: 1995. Accessed: 11/2/02.

20. Kobryn, Cris. Communications of the ACMS. "UML 2001: A Standardization Odessy." http://www.omg.org/attachments/pdf/UML_2001_CACM_Oct99_p29-Kobryn.pdf Oct. 1999, Vol. 42, No. 10.

21. Object Management Group. "Introduction to OMG’s Unified Modeling Language." http://www.omg.org/gettingstarted/what_is_uml.htm . Last updated: 8/2/02. Accessed: 10/15/02.

22. Collins, Mark. Object OrientedAnalysis and Design Using UML. Ratio Group

http://www.ratio.co.uk/white.html . Last updated: unknown. Accessed: 10/31/02.