Object Oriented Analysis and Design
Statement and Confirmation of Own Work Programme/Qualification name: Bsc (Hons) Business Computing and Information Systems All NCC Education assessed assignments submitted by students must have this statement as the cover page or it will not be accepted for marking. Please ensure that this statement is either firmly attached to the cover of the assignment or electronically inserted into the front of the assignment. Student Declaration I have read and understood NCC Education’s Policy on Academic Dishonesty and Plagiarism. I can confirm the following details:
Student ID/Registration number:00103719 Name:JACOB TACHIE-MENSON Centre Name:IPMC Module Name:OBJECT ORIENTED ANALYSIS AND DESIGN Module Leader:MR. PETER BIELKOWOICZ Number of words: I confirm that this is my own work and that I have not plagiarised any part of it. I have also noted the assessment criteria and pass mark for assignments. Due Date:15TH OCTOBER, 2010 Student Signature: Submitted Date: 15TH OCTOBER, 2010 TABLE OF CONTENT INTRODUCTION TASK ONE Use Case Analysis INTRODUCTION Doclib Library is the business case study for this assignment.
It is a private document library with the business operations of storing and ‘short term’ lending of various documents. With reference to the business case study specified in the Object Oriented Analysis and Design Autumn 2010 assignment, the current library’s processes are executed in a manual system of operation. The demand of this task is to produce a computerised system for the specified functions or services enlisted in the case study by producing an object – oriented model of the system to be developed to support the business using Unified Modelling Language (UML).
The assignment practically consists of the below tasks: * The first task involves analysis and design of a system for Doclib library using UML. * The second task was related to Communication/Collaboration Diagrams * The third task is to explain how various UML diagrams were developed and * The forth task is producing this report. TASK ONE 1. 1USE CASE ANALYSIS Use case analysis is a process as described by Ivar Jacobson in his book Object-Oriented Software Engineering, as a way of understanding the nature f interaction between users of a system and the internal requirements of that system. According to Jacobson, a use case model specifies the functionality of a system as well as a description of what the system should offer from the user’s perspective (Loshin, 2001). This offers a means of explanation and communication between system users and developers leading to the exploration and identification of scenarios which form part of the system requirement. (Programming Methods ). This modelling involves the use of UML methodology in producing the various models.
The Object Management Group (OMG) specification states: “The Unified Modelling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components. ” Use case models are practically used to: provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model (Constantine and Lockwood 1999, Ambler 2004) or a business model (Rational Corporation 2002); * model the analysis of usage requirements in the form of a system use-case model (Cockburn 2001) * communicate the scope of a development project According to (Introduction to UML 2 Use Case Diagrams, n. d), use case diagrams depict: * Use cases: It describes a sequence of actions that provide something of measurable value to an actor, and is drawn as a horizontal ellipse. USE CASE Actors: An actor is a person, organization, external system or local process (e. g. , system clock) that plays a role in one or more interactions with a system. Actors are drawn as stick figures, annotated by the diagram below: ACTOR * System Boundary (optional): A rectangle is drawn around the use cases, called the system boundary box. This makes an indication of the system scope. Anything within the box represents functionality that is in scope and anything that is outside the box is not. SYSTEM BOUNDARY * Packages (optional): Packages are UML constructs that enable the organization of model elements (such as use cases) into groups.
They are depicted as file folders and can be used on any UML diagrams. PACKAGE * Associations: Association between actors and use cases are indicated by solid lines with an optional arrowhead on one end of the line. The arrowhead is often used to indicate the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. A UML relationship is a type of model element that adds semantics to a model by defining the structure and behavior between the model elements. These relationships include the <<include>>, <<extend>> and generalization-specialization relationships.
An include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use-case model whereas an extend is a generalization relationship where the extending use case continues the behavior of the base use case by conceptually inserting additional action sequences into the base use case(Ambler, 2005 p. 40). Generalization-specialization (Gen-Spec) – The gen-spec use case adds features to a generic use case. The gen-spec use case nherits features of the base use case. The gen spec can be used for use cases and actors since both can be specialized (UML Use Case Relationships, 2010). 1. 1. 1USE CASE DIAGRAM FOR DOCLIB LIRARY SYSTEM The use case analysis made on the case study identified two important actors, the librarian and the reader besides two system actors, the payment processor and the timer. The <<system>> stereotype is applicable to system/concrete diagrams that reflect architectural decisions made for a system as opposed to essential diagrams (Constantine and Lockwood 1999).
The use cases identified included borrow document, return document, register document, delete document, add document, subject search, deregister reader, view document, issue document/password, make reservation, select subject, create loan, calculate loan fee, check availability, issue fine, search document, get document notification, print document, use short/three day loan and use all loan category. USE CASE DIAGRAM FOR DOCLIB LIBRARY SYSTEM Fig. 1. 1 showing use case diagram for doclib library 1. 1. 2USE CASE DESCRIPTION FOR SELECTED FUNCTIONAL REQUIREMENTS 1. 1. 2. BORROW DOCUMENT Use case name:Borrow Document Actor:Librarian Brief description:To loan a document from the library for a short, three day or one week loan category. Detailed description: Actor action| System response| 1. Input login details to the library system as a precondition 2. Checks the availability of document (i. e document status)by doc_code 3. Assuming document is available, loan details are input 4. Select payment method and makes payment 5. Gets paper document or password and exit borrow document function 6. Log off to exit application| Validate login etails and grants access to system for correct login detailsChecks and returns document status message when available or unavailable (on loan or reservation). Checks and register new reader or update existing reader. Calculate and display loan feeRecords and create loan by storing details. Issues password or grant access to document. Borrow document function exits. Application exits| 1. 1. 2. 2SUBJECT SEARCH Use case name:Subject Search Actor:Librarian, Reader Brief description:To search for all the documents “belonging” to a specified subject. Detailed description: Actor action| System response| Input login details to the library system as a precondition * Initiate search by selecting subject search from menu as a precondition * Select subject(s) from displayed list * Accesses document and exit subject search function * Log off to exit application| Validate login details and grants access to system for correct login detailsDisplays all subjects to commence actual searchSearches and displays all document records for the selected subject(s)Closes subject search functionApplication exits| 1. 2CLASS ANALYSIS The technique used to identify entities and the relationship between them is known as class analysis.
This technique is used in specifying the structural properties of the classes that model the concept of the problem domain. It is described by means of class diagram in which no operations are defined, textual constraints that define conditions the information must satisfy but can not be graphically specified in UML, with derived attributes that specify information from other elements of the class diagram (Nemati et. al 2004, p. 775). 1. 2. 1CLASS DIAGRAM 1. 2. 1. 1IDENTIFYING CLASSES AND RELATIONSHIPS BETWEEN CLASSES The classes identified of the doclib library are the class Document (with subclasses aper and computerized), class Reader (with subclasses individual and institutional), class Subject, class Loan (with subclasses short, three day and one week), class Reservation and class Librarian.
1. 2. 1. 2ENTITY CLASS DIAGRAM FOR THE DOCLIB LIBRARY SYSTEM 1. 2. 2DETAILED DESCRIPTION OF SELECTED CLASSES 1. 2. 2. 1CLASS READER Class name:Reader Brief description:Responsible for storing and managing a reader’s information in the system. It has two subclasses specializing the type of a reader Classification:Superclass Attributes: Attribute name| Data type| Description| Notes| eader_no| String| Unique code for each reader| This uniquely identifies each registered reader in the library system| reader_name| String| Name of a particular reader| This will contain the full name of a particular reader | date_of_registration| Date| Reader’s registration date| Date at which a new person is registered into the system as a reader| date_of_last_loan| Date| Date of last loan by reader| To aid system timer to calculate inactive period of a reader to enable it perform the deregister of an inactive reader| frequency| Integer| How regular a reader is| This will enable system to calculate discount due for an active member required for calculating the actual loan fee| Operations: Operation name| Parameters(name, type)| Results (type only)| Description | Notes| Reader| | | Reader constructor method/operation|
It’s used to create a new instance of the reader class| searchSubject| subject, string| String| Searching for all documents belonging to a specific subject| It produces a list of document items based on subject area| viewDocument| password, string| String| Applicable when viewing computerized documents| Password is input to access specified documents| rintDocument| | | Printing a computerized document| A computerised user can print document on request| useDocument| doc_id, string| string| Have access rights to use document as part of borrowing function| After requesting to borrow and paying loan fee for a document, the reader gets document to use| usePassword| password, string| String| Uses password to access computerized documents| A unique access code to a specific computerized document on the system| reserveDocument| doc_id, string| | Reserve document currently unavailable| Does reserve a document that is on loan and currently unavailable for loan. | getDocumentNotification| | | Receives and respond to notification on document reservation made| Corresponding reader of a returned document is notified| Class name:Individual Brief description:Responsible for storing and managing an indivual reader’s information in the system.
Classification:Subclass Attributes: Attribute name| Data type| Description| Notes| date_of_birth| Date| An individual reader’s date of birth| Stores an individual reader’s date of birth| Operations: Operation name| Parameters(name, type)| Results (type only)| Description | Notes| useShortThreeDayLoan()| | | Have the options short or three day loan categories| Can only use short or three day loan categories out of the available categories for a loan. | Class name:Institutional Brief description:Responsible for storing and managing an institutional reader’s information in the system. Classification:Subclass Attributes: Attribute name| Data type| Description| Notes| ype_of_institution| string| The type of institution recognised as a reader in the system| Stores information on the type of institution | Operations: Operation name| Parameters(name, type)| Results (type only)| Description | Notes| useAllLoanCategory()| | | Have the right to all loan categories| Can use all available categories for a loan. | 1. 3USE CASE REALIZATION Because use cases capture requirements at a functional level, UML provides a mechanism for tracing functional requirements to their actual implementation, called use case realization. A use case realization is an expression of a use case’s flow of events in terms of objects in the system. In UML, this event flow is expressed with collaborations.
Each with a set of sequence and collaboration diagrams (Conallen, 2003). The important of use case from the use case realization decouples the process of gathering requirements. This separation allows developers to focus on well-defined problem at a time and avoid dealing with design issues during the phases of analysis and vice versa. (Paparjorgji and Pardalos 2006, p. 121) According to (Rational unified process, 2001), each use case realization can have interaction object which typically consist of collaboration and sequence diagrams. These diagrams express the behaviour of the use case in terms of collaborating objects. The work of Conallen (2003, p. 26) further describes that although, collaboration diagrams are semantically the same as sequence diagrams, each diagram expresses the information with a different view. Sequence diagrams focus on the time dimension where everything is rigidly placed along the time axis vertically, from top to bottom whereas collaboration diagrams focus on object instances, not time. The objects in a collaboration diagram can be placed anywhere in the diagram, where a single represents all messages from one object to another. Each message is numbered to preserve the time dimension and they are lumped together on the one association between each object. 1. 3. 1SEQUENCE DIAGRAM FOR “BORROW DOCUMENT” USE CASE
Below is a sequence diagram depicting the interaction between the librarian, the library system interface, the database, document, loan and payment system during the borrow document function of the system. The processes in borrowing a document (computerized or paper) involves the librarian gaining authorized access to the system, checking availability of the document and creating loan to get the document. 1. 3. 1SEQUENCE DIAGRAM FOR “BORROW DOCUMENT” USE CASE Searching for a subject in the doclib library system is done by two actors, the librarian or reader. This is depicted in the below sequence diagram showing the interaction between the actors, the library system interface, the database, document and subject during the borrow document function of the system.
The process in searching for subject(s) involves the actors gaining authorized access to the system, selecting from a list of displayed subjects and possibly choosing a document for that particular subject. TASK TWO 2. 1INVESTIGATION OF COMMUNICATION AND COLLABORATION DIAGRAMS Collaboration diagrams, also called communication diagrams are used to model the behavior of objects in use case diagram. Communication diagrams show the exchange of messages (or interactions) between objects as well as the relationships (often called context). That is, it illustrates the structural relationship objects and messages that must interconnect them to accomplish an activity (Kogent Solutions Inc. , 2007 p1562). Grady (2006: p272) states: ‘A collaboration diagram is one of two kinds of interaction diagrams used in UML.
These interaction diagrams provide a transition between the requirements analysis work performed in association with use case, state, and activity diagrams and the detailed design of a software system. Thus the interaction diagrams offer a “preliminary design environment. ”’ 2. 1. 1FEATURES OR ELEMENTS AND USES OF COLLABORATION DIAGRAMS A collaboration diagram shows the interaction among objects. It can be thought of as an extension to the class diagram, showing not only the associations among objects but also the messages that the objects send to one another. Collaboration diagram illustrate the class roles and association roles among them that are relevant to realizing the behavior that they depict.
They include message flows, attached to the association roles. (B’Far 2005, p. 193) There are three primary elements of collaboration diagram. This includes objects, links and messages. * Blocks represent objects conceived to implement functionality and behavior exposed in use case, state, and activity diagrams. These blocks are interconnected by links that correspond to messages among the objects. (Grady, 2006 p1562). * Links are defined as the relationship among objects across which messages can be sent. These are illustrated as solid lines between two objects. An object interact with, or navigates to, other objects through its links to these object (Guidelines: Collaboration Diagram, 2002). A message is a communication between objects that convey information with the expectation that activity will ensue. A message is shown in collaboration diagram as a labelled arrow placed near a link. The arrow points along the link in the direction of the target object and labelled with the name of the message, and its parameters (Guidelines: Collaboration Diagram, 2002). They are useful for exploring the manner in which one object affects another, as well as to detail its behaviour, and are also excellent at illustrating the links between objects 2. 1. 2CREATING OR DRAWING COLLABORATION DIAGRAMS When creating collaboration diagram, it is useful to begin by modelling the objects that are going to participate in the interaction.
With the objects established, one can then model the relationships among the interaction (B’Far 2005, p. 193). Drawing collaboration diagram uses the free-form arrangement of objects and links without any strict adherence to object positioning. 2. 1. 3COLLABORATION VS. SEQUENCE DIAGRAMS Collaboration diagrams are semantically the same as sequence diagrams, nevertheless, collaboration diagram illustrates the interactions of various objects and focuses on the interactions playing a smaller role whereas sequence diagram emphasize the temporal ordering of series of events and focuses on the passage of time respectively (Tonella & Potrich, 2005: p89). 2. 1. 4ADVANTAGES AND DISADVANTAGES According to the work of Larman (2002, p. 99), the advantages of collaboration diagrams include its flexibility to add new objects in two dimensions and better illustrate complex branching, iteration, and concurrent behaviour. Besides the mentioned advantages, its disadvantages are that it is difficult to see sequence or messages and more complex notations. TASK THREE UML diagramming technique was used to offer a range of views of the system. This promoted the development process model due to the use – case driven and architecture centric nature of the project tasks (Bezivin and Muller 1999, p. 441). This has presented a common model from which to observe, review and implement the system. The development of this project went through a series of processes found in most system development projects.
It covered the processes of: * Requirement gathering * Analysis * Design and excluded the development and deployment stages which were considered out of the scope of this project. 3. 1REQUIREMENTS GATHERING This is the first stage of the development process and involved a critical analysis of the existing system to gain accurate record of the system. This helped in breaking the proposed system into manageably smaller components to identify the scope on what the proposed system is required to do. This stage was broken down into the following subsections: 3. 1. 1Discovering Business Process At this section, the case study was analyzed to identify the existing business processes.
The processes identified were: * Add a document record * Delete a document record * Borrow a document * Return a document * Register a reader * De-register a reader * Subject search * Reserve a document * View a document 3. 1. 2Domain Analysis This section covered understanding the working domain of the system. The system boundary (Doclib library system) was identified along with its entities. The below objects were identified to create the class diagram of the system: * Reader * Librarian * Document * Reservation * Loan * Subject Entities * Reader * Librarian * Timer (system) * Payment Processor (system) 3. 1. 3Discovering system requirements
The entities (external and system) were linked to identified functions in the business process section. This included: * The librarian must have access to the system, add and delete document record, borrow and return document, register reader and search subject. * The reader must be able to search subject, view and reserve document. * The system must be able to de-register a reader and calculate loan fee. The outcome of this stage was a clear and concise definition of system requirements for the proposed system. 3. 2ANALYSIS This stage undertook critical analysis on the specified requirements. This activity was broken down into a series of sub-activities as follows: 3. 2. 1Understanding System Usage
This included identifying main actors and their functions, system boundary, other use cases and interactions and stereotyped dependencies between use cases and actors to effectively produce a high-level use case diagram. 3. 2. 1. 1Flesh out use cases Description of use cases related to the “borrow document” and “search subject” functional requirements were outlined. 3. 2. 1. 2Refine the class diagram The identified classes were analyzed. The multiplicities, generalizations, associations and names of associations were outlined with the classes’ attributes and operations. 3. 2. 1. 3Define the interactions among objects Sequence and collaboration diagrams for “borrow document” and “search subjects” were developed to illustrate interactions between objects. 3. 3DESIGN
The use cases, classes, sequence and collaboration diagrams are used in designing system solution. This is done iteratively until all design of functional requirements is effective and complete.
PROJECT SUMMARY BIBLIOGRAPHY Ambler, W. Scott (2005) The elements of UML 2. 0 Style, Cambridge University Press, New York. Constatine, L. L and Lockwood, LAD (1999), Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Illustrated, reprint. Addison-Wesley. Ambler, W. Scott (2004) The object primer: agile model-driven development with UML 2. 0. 3rd Edition. Cambridge University Press, New York. Cockburn, A. (2001) Writing Effective Use Cases. Reprinted. Addison-Wesley Agile Modeling 2003-2010: Introduction to UML 2 Use Case Diagrams Available on: http://www. agilemodeling. com/artifacts/useCaseDiagram. htm,