Unit-1 INTRODUCTION SYLLABUS: Categories of Information systems-traditional paradigm vs. Object oriented paradigm-objects and Classes-Inheritance-Object relationship-examples of UML class modeling-unified Process- Iteration and incrementation within the unified process. INTRODUCTION : Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements) and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Benefits Easy to understand Maintainability Data re-use 1.1 CATEGORIES OF INFORMATION SYSTEMS A system is a set of artifacts (components) that together achieve some outcome. An information system is a system that achieves a business outcome. It collects, manipulates, stores and reports information regarding the business activities of an organization in managing the operations of the business. The two major categories of computerized Information systems are Custom information Systems Commercial off-the-shelf (COTS) packages 1
Custom Information System (CIS) is an information system that has been developed for one specific client. For example, the information system developed for Jethro s Boot Emporium is a custom Information System- the boot fashion trend detection component is used by no other company. The 3 main stakeholders when a Custom Information System is developed are The Client, who is paying for the Information System to be developed The future Users of the Information system. The developers of that information system The task of the developers is to determine the needs of the client and to develop an information system that satisfies those needs and can effectively be utilized by the users. Another example of a custom information system is a management information system for a major car rental company. Disadvantage: Custom Information Systems are expensive and an organization might be tempted to recoup some of the cost by selling a copy of its custom information system to its competitor. For this reason, the resale market for this system is small. CIS incorporates the business model of organization that commissioned it and selling a copy of such a CIS means giving away proprietary information to a competitor. Commercial-Off-The-Shelf (COTS) is also called Shrinkware, because the diskettes or CDs on which the package used to be supplied were placed in a box together with the manual and the box was then shrink-wrapped. Nowadays, however, COTS packages are frequently downloaded over the Internet- called as Clickware. There are only two major stakeholders for a COTS package: The Developers The Users COTS packages are intended to provide functionality that will satisfy the needs of as large a user base as possible. Some COTS are relatively small and cheap and are intended to satisfy the information system needs of smaller businesses. COTS packages include TurboTax, Microsoft Excel and Peachtree Accounting System. 2
In contrast, an Enterprise Resource Planning (ERP) system such as PeopleSoft or SAP is a huge package intended to provide almost all the information needs of a large corporation, including accounting, payroll, inventory, sales, purchasing and personnel and so on. Thus COTS packages like ERP systems lie between the pure CIS and COTS packages that are unchangeable. 1.2 TRADITIONAL INFORMATION SYSTEM DEVELOPMENT The information system life cycle is the way that an information system is constructed, as it is almost always easier to perform a sequence of smaller tasks than one large task, the overall life cycle is broken into a series of smaller steps called phases. The number of phases varies from organization to organization. Typically there are six phases Requirements phase In this phase, the client s requirements are extracted. The client and the future users of the information system to be developed interact with the information system development team in order to determine the client s needs. The results of this study are presented in the form of a requirements document. The requirements document is only a few pages long, with the specific needs listed as bullet items. Analysis Phase The aim is to draw up the specification document. The specification document lays out what the information system has to do. If the delivered information system satisfies the specifications, then the client pays the developers for the information system. If not the developers have to fix the information system until it satisfies the specifications. The specifications describe what the system has to be able to do. Once the specification document has been signed off by the client, the project management plan can be drawn. This detailed plan includes a budget, staffing needs and a list of what will be delivered to the client and when it will be delivered. Design Phase In this the members of the development team describe how the information system is developed. Typically the system is broken into smaller pieces called modules. 3
Each module is designed in detail; the development team has to describe the algorithms used by the module (how the module performs the task) and data structures within the modules (data on which the module is to operate). The result is represented in the form of a design document. Implementation phase The design of the modules is given to the design team to translate into an appropriate programming language. COBOL is the world s most widely used programming language, whereas the modern information systems are often implemented in C++ or Java. Modules are integrated (combined) to form the complete information system. Maintenance phase After the information system has been installed, it will need to be modified either to remove any remaining faults from the system or because the system needs to be extended in some way. Retirement Finally after 10 or 15 years of maintenance, an information system is retired if longer performs a useful service. it is no There is no planning phase o Beginning of the project-preliminary planning takes place to manage the requirements and analysis phases o To draw management plan-budget, staffing requirements and detailed schedule o Project management need to monitor the project management plan and be on the watch for any derivation from the plan. There is no planning phase instead; planning activities are carried out all through the life cycle. There is no testing phase o Validation and verification is missing 4
There is no documentation o It is necessary to update each information of the system development. It is necessary when the developer changes, as the document designing will be tedious. o Essential for back reference in case of troubleshooting. o Necessary for testing a new client s requirement. o Maintenance is impossible if there is no documentation 1.3 Traditional Paradigm Vs Object-Oriented Paradigm The computer age started in the 1940s, so Information Systems (IS) are hardly more than 50 years old. Developing IS was initially considered a creative skill; individuality was highly prized. However, as larger computers became more affordable, it became possible to run an information system that was too big to be developed by just one person, if that information system was to be completed by the deadline specified by the client. Instead, IS began to be developed by teams. Furthermore skill specialization became the industry norm. Instead of information technology professionals being involved in all the phases- 2 separate professions arose: System analysts to perform the requirements, analysis and design phases and Programmers to do the implementation. The first systematic approach to information is called the Traditional paradigm /methodology or Structured methodology /paradigm. Initially this method was extremely successful. This was treated as methodical discipline rather than a creative activity. The quality of Information system improved and the delivery of the IS on time and within the budget started to become a realistic expectation. During the 1980s, the cost of hardware continued to decrease fast. As larger computers became more affordable, the size of IS continued to grow. But larger the IS, the less successful the traditional paradigm proved to be. Finally, the IS community realized that the traditional paradigm had outlined its usefulness and something more was needed. 5
Traditional method went well with small scale IS (approx. 5000 lines of code), but not with medium scale IS (approx. 50000 lines of code) and long scale IS (approx. 5000000 lines of code). This method ignored the data in favor of the operations. In contrast, the Object-Oriented Paradigm pays equal attention to operations and data. The Standish Group is a research firm that analyses the development of IS. Their study of 280000 development projects completed in 2000 and is summarized as The financial and legal implications of unsuccessful projects are horrendous. A survey conducted by the Cutter Consortium revealed that an astounding 78 percent of the information technology organizations surveyed have been involved in disputes that ended up in litigation In 67% of the disputes, the functionality or performance of the information system as delivered did not meet up to the claims of the developers In 56% of the disputes, the promised delivery date slipped several times In 45% of the disputes, the defects were so severe that the information system was unusable. These reasons forced organizations to change to the object-oriented paradigm. 1.4 OBJECTS & CLASSES A class is a set of objects that share a common structure (instance variables) and behavior (methods) and the inheritance for objects. The chief role of a class is to define the properties and procedures (state and behavior) and applicability of its instances. 6
Each object is an instance of a class. Objects perform operation in response to messages. e.g. when brake pedal is pressed, message is passed to the vehicle for it to stop A method implements the behavior of an object. It is a function or procedure that is defined for a class and typically can access the internal state of an object of that class to perform some operation. Behavior denotes the collection of methods that abstractly describes what an object is capable of doing. Each procedure defines and describes a particular behavior of an object. 1.5 INHERITANCE Inheritance is the property of object-oriented systems that allows objects to be built from other objects. Inheritance is a relationship between classes where one class is the parent class of another (derived) class. The parent class is known as base class or super class. The child class is known as derived class or sub-class. Sub-class inherits all of the properties and methods defined in Super class. Sub-classes generally add new methods and properties specific to that class. Thus inheritance allows classes to share and reuse behaviors and attributes. It is a top-down relationship. 7
The Bank Account Class is a class and the Current Account Class is a subclass of Bank Account Class. The open triangle below Bank Account Class tells that Current Account Class has all the features of Bank Account Class (derived part) but in addition has features of its own that are specific to Current Account Class (incremental part) such as Calculate interest. The different ways of describing the relationship are 1) Current Account class is a subclass of Bank Account Class 2) Bank Account Class is a super class of Current Account Class 3) Current Account class is a specialization of Bank Account Class 4) Bank Account Class is a generalization of Current Account Class 5) Current Account class is a Bank Account Class 6) Bank Account Class is the base class; Current Account Class is the derived class 7) Bank Account Class is the parent class; Current Account Class is the child class Therefore Current Account class inherits from Bank Account Class These ideas can be extended to Savings Account Class as well. Thus both Current Account Class and Savings Account Class inherit all the features from Bank Account Class along with its own features. Types of Inheritance : 1) Single Inheritance: Derivation of class from only one base class is called single inheritance. 2) Multiple Inheritance:Derivation of class from several base class is called multiple inheritance. 8
3) Hierarchical Inheritance: Derivation of several classes from a single class is called hierarchical inheritance. 4) Multilevel Inheritance: Derivation of a class from another derived class is called multiple inheritance. 5) Hybrid Inheritance: Derivation of a class involving more than one form of inheritance is called hybrid inheritance. 1.6 OBJECT RELATIONSHIPS GENERALIZATION Generalization is a mechanism for combining similar classes of objects into a single general class. It identifies commonalities among a set of entities. The commonality may be attributes, behavior or both. Inheritance can be equalized to inheritance. Inheritance is programming implementation of generalization. Generalization is a bottom-up process. SPECIALIZATION It is an ability of an object to inherit operations and attributes from the super class or base class with possible restrictions and additions. Figure : Generalization & Specialization AGGREGATION Aggregation represents a relation contains, is a part of and whole- part relation. It is indicated by a line adorned on the whole by a hollow diamond along with name of relationship and cardinality. Example: a Library contains Books (one-to-many) 9
Figure: Aggregation ASSOCIATION An association is a connection between classes, a semantic connection between objects of classes involved in the association. Association typically represents has a or uses relationships. It is indicated by a line, sometimes with arrow indicating unidirectional relationship, adorned by the name of the relation, and the ends of the line adorned by cardinality of relationship and optionally by the roles connected to each class. It is also known as Client-Server association or Consumer-Producer association. Figure : Association POLYMORPHISM The word poly means many and morph meaning form. It is the ability of same operation to apply to different classes. Basically the ability to define a method in a class and to have that method exists for all subclasses of that class even when the subclasses a very different in their behavior. It allows writing generic, reusable code more easily because we can specify general instruction and delegate the implementation details to the objects evolved. 10
1.7 UNIFIED MODELING LANGUAGE System is any process or structure. Example: Organizational structure of Corporation-Health Services, National economy Model is an abstract representation of a system, constructed to understand the system prior to building or modifying it. Two types of models are Static- it is a snapshot of system parameters at specific point of time. E.g. UML diagrams Dynamic- it is viewed as a collection of procedures or behaviors taken together of a system over time. The relationships show how the business objects interact to perform tasks. Modeling Building a model for a software system prior to its construction is an essential as having a blueprint for building a large building. Rigorous modeling is essential. It must include Model elements- which form the fundamental modeling concepts and semantics. Notation- visual rendering of model elements Guidelines- expression of usage within the trade 11
Benefits Clarity Advantages Familiarity Maintenance Simplification Models make it easier to express complex ideas Reduction of complexity by separating the unimportant aspects from those are important Models enhance and reinforce learning and training Cost of the modeling analysis is much lower than the cost of similar presentation conducted with a real system. UML The unified modeling language (UML) is a language for specifying, constructing, visualizing and documenting the software system and its components. The UML is a graphical language with sets of rules and semantics. The primary goals in the design of the UML are Provide users a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts. Integrate best practices and methodologies UML has 9 graphical diagrams o Class diagram(static) o Use-case diagram(static) o Behavior diagram(dynamic) 12
o Interaction diagram o Sequence diagram o Collaboration diagram o State chart diagram o Activity diagram o Implementation diagram. o Component diagram o Deployment diagram. Static Diagrams: 1. CLASS DIAGRAMS Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system. Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes. Symbols & Notations Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third. Visibility Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class. 13
Figure:Visibility Multiplicity (Cardinality) Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only. Figure: Multiplicity Composition and Aggregation Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate. 14
Figure: Composition and aggregation 2. USE CASE DIAGRAM Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users. Symbols and Notations System Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries. Use Case Draw the use cases using ovals. Label the ovals with verbs that represent the system's functions. 15
Actors Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype. Relationships Illustrate relationships between actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends relationship indicates alternative options under a certain use case. Figure : Use case Diagram for Bank Information System 16
BEHAVIOR DIAGRAM (DYNAMIC) Interaction Diagrams: The interaction diagrams are divided into Sequence diagram Collaboration diagram 3. SEQUENCE DIAGRAMS Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. Symbols and Notations Class roles Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes. Activation Activation boxes represent the time an object needs to complete task. 17
Messages Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks. Various message types for Sequence Lifelines Lifelines are vertical dashed lines that indicate the object's presence over time. Destroying Objects Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X. 18
Loops A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting the loop at the bottom left corner in square brackets [ ]4 4.COLLABORATION DIAGRAM A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system. Symbols and Notations Class roles Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don't list object attributes. Association roles Association roles describe how an association will behave given a particular situation. Association roles can be drawn using simple lines labeled with stereotypes. 19
Messages Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead number messages in order of execution. Sequence numbering can become nested using the Dewey decimal system. For example, nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. A condition for a message is usually placed in square brackets immediately following the sequence number. Use a * after the sequence number to indicate a loop. 5. ACTIVITY DIAGRAM An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of state-chart diagram, it uses some of the same modeling conventions. Symbols and Notations Action states Action states represent the non-interruptible actions of objects. Action Flow Action flow arrows illustrate the relationships among action states. 20
. Object Flow Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to an object means that the action creates or influences the object. An object flow arrow from an object to an action indicates that the action state uses the object. Initial State A filled circle followed by an arrow represents the initial action state. Final State An arrow pointing to a filled circle nested inside another circle represents the final action state. Decision A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else." 21
Synchronization A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining. Implementation diagrams: Implementation diagrams can be divided into o Component diagram o Deployment diagram 6. COLLABORATION DIAGRAMS Component diagram describes the organization of the physical components in a system. Symbols and Notations Component A component is a physical building block of the system. It is represented as a rectangle with tabs. 22
Interface An interface describes a group of operations used or created by components. Dependencies Draw dependencies among components using dashed arrows. 7. DEPLOYMENT DIAGRAMS Deployment diagrams depict the physical resources in a system including nodes, components, and connections. Symbols and Notations Component A node is a physical resource that executes code components. 23
Association Association refers to a physical connection between nodes. Place components inside the node that deploys them. 1.8 THE UNIFIED PROCESS Problems arose when large information systems were developed using the traditional paradigm, especially when the resulting information systems were maintained. By the mid 1980s it had become clear that a better paradigm was needed. The object oriented paradigm proved to be the solution. Over the next 10 years more than 50 different object-oriented methodologies were published. Three of the most successful methodologies were Booch s methodology Jacobson s Objectory. Rumbaugh s Object modeling Technique. Taking the information system world by storm with UML was not enough for the three Amigos. Their next endeavor was to publish a complete object-oriented analysis and design methodology that unified their three separate methodologies. This unified methodology was first called the Rational Unified Process (RUP) [The word Rational because at that time all the three Amigos were senior managers at Rational Inc.] The unified process is a series of steps that will result in the constructions of an information system. In fact, there is no such single one size fits all methodology could exist, because there is such a wide variety of different types of information systems. For example, there are different application domains, such as banking, insurance or manufacturing. Thus the Unified Process can be viewed as an Adaptable methodology. 24
1.9 ITERATIVE AND INCREMENTAL WITHIN THE UNIFIED PROCESS The Unified Process is a modeling technique. A model is a set of UML diagrams that represent one or more aspects of the information system wanted to be developed. A major reason for using a graphical representation is that UML diagrams enable information technology professionals to communicate with one another more quickly and more accurately than if only verbal descriptions were used. The Unified Process is an iterative and incremental methodology. Each workflow consists of a number of steps and in order to carry out that workflow, the steps of the workflow are repeated until the members of the development team are satisfied that they have an accurate UML model of the information system they want to develop. The implication is that system analysts, no matter how outstanding they may be, almost never get the object-oriented analysis and design right the first time. It is been subjected to Miller s law-that one cannot think about everything at the same time, so a set of seven chunks or so can be handled at once and then another set where the developer can gain more knowledge about the information system and modify the UML diagrams in light of the additional information. Thus more knowledge about the real-world system is gained to make more accurate (iteration) and is extended accordingly (incrementation) until accurate representation of the information system is developed. 25