Ooad Fll Notes1.pdf

2015 CS1009 OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT I – INTRODUCTION (8 Hours) 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

UNIT II – UML AND THE UNIFIED PROCESS (9 Hours) Overview of requirements – Initial understanding of the domain – Business Model – Requirements workflow – Osbert Oglesby case study – MSG Foundation case study – Revising the requirements – MSG Foundation Case Study – Continuing the requirements workflow – MSG Foundation Case Study - Refining the revised requirements – MSG Foundation Case Study. UNIT III - OBJECT ORIENTED ANALYSIS (10 Hours) Extracting Entity Classes – Initial dynamic model – Extracting control classes -refining use cases – Incrementing the Class Diagram – Initial dynamic model – MSG Foundation case study – Revising the entity classes – Extracting – USE case realization – MSG Foundation case study – Incrementing the Class Diagram – More on use cases – Risk. UNIT IV – OBJECT ORIENTED DESIGN WORKFLOW (10 hours) Design workflow – Format of the Attributes – Allocation of Operations – Osbert Oglesby Case Study – Workflows of the Unified Process – Phases of the Unified Process – Class Diagrams – Use Case Diagrams – Interaction Diagrams – State Charts – Package Diagrams – Deployment Diagrams. UNIT V – TESTING AND MANAGEMENT ISSUES (8 hours) Quality Issues – Non Execution Based Testing – Execution Based Testing – Cost Benefit Analysis – Risk Analysis – Improving the Process – Metrics – CPM/PERT – Choice of Programming Language – Reuse Case Studies – Portability – Planning and Estimating Duration and Cost – Testing the Project Management Plan – Maintenance and the Object Oriented Paradigm – CASE Tools for Maintenance.

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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 it is no longer performs a useful service. 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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

 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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

Benefits  Clarity  Familiarity  Maintenance  Simplification Advantages  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

A. John Blesswin [101922]

o Interaction diagram o Sequence diagram o Collaboration diagram o o o o o

State chart diagram Activity diagram Implementation diagram. Component diagram 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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

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

A. John Blesswin [101922]

Unit-2 UML AND THE UNIFIED PROCESS SYLLABUS: Overview of requirements-Initial understanding of the domain- Business Model-Requirements workflow -Osbert Oglesby case study-MSG Foundation case study revising the requirementsMSG Foundation case study-Continuing the requirements workflow- MSG Foundation case study refining the revised requirements- MSG Foundation case study. 2.1 OVERVIEW OF REQUIREMENTS  First, gain an understanding of the application domain (domain, for short) o (The specific business environment in which the information system is to operate)  Second, build a business model o Use UML to describe the client’s business processes  Third, use the business model to determine the client’s requirements  Then iterate (“repeat”) the above steps FLOWCHART OF THE REQUIREMENTS WORKFLOW

1

A. John Blesswin [101922]

DEFINITIONS  Discovering the client’s requirements o Requirements elicitation (or requirements capture) o Methods include interviews and surveys  Refining and extending the initial requirements o Requirements analysis 2.2 INITIAL UNDERSTANDING OF THE DOMAIN  Every member of the development team must become fully familiar application domain o Correct terminology is essential  We must build a glossary o That is, a list of technical words used in the domain, and their meaning Initial Understanding: Osbert Oglesby Case Study  Osbert Oglesby, Art Dealer, needs an information system to assist him in buying and selling paintings  Obtaining domain knowledge is the first step  Osbert is interviewed to obtain the relevant information GLOSSARY: OSBERT OGLESBY CASE STUDY

2.3 BUSINESS MODEL  A business model is a description of the business processes of an organization  The business model gives an understanding of the client’s business as a whole o This knowledge is essential for advising the client regarding computerization  The systems analyst needs to obtain a detailed understanding of the various business processes o Different techniques are used, primarily interviewing 2

A. John Blesswin [101922]

2.3.1 INTERVIEWING  The requirements team meet with the client and users to extract all relevant information  There are two types of questions o Close-ended questions requires a specific answer o Open-ended questions are asked to encourage the person being interviewed to speak out  There are two types of interviews are asked, frequently o In a structured interview, specific preplanned questions close-ended o In an unstructured interview, questions are posed in response to the answers received, frequently open-ended  Interviewing is not easy o An interview that is too unstructured will not yield much relevant information o The interviewer must be fully familiar with the application domain o The interviewer must remain open-minded at all times  After the interview, the interviewer must prepare a written report o It is strongly advisable to give a copy of the report to the person who was interviewed 2.3.2 OTHER INFORMATION GATHERING TECHNIQUES  Interviewing is the primary technique  A questionnaire is useful when the opinions of hundreds of individuals need to be determined  Examination of business forms shows how the client currently does business  Direct observation of the employees while they perform their duties can be useful o Videotape cameras are modern version of this technique o But, it can take a long time to analyze the tapes o Employees may view the cameras as an unwarranted invasion of privacy 2.3.3 USE CASES  A use case models an interaction between the information system itself and the users of that information system (actors)  Example:

 A use case shows the interaction between o The information system and o The environment in which the information system operates 3

A. John Blesswin [101922]

 Each use case models one type of interaction o There can be just a few use cases for an information system, or there can be hundreds  The rectangle in the use case represents the information system itself  An actor is a member of the world outside the information system  It is usually easy to identify an actor o An actor is frequently a user of the information system  In general, an actor plays a role with regard to the information system. This role is o As a user; or o As an initiator; or o As someone who plays a critical part in the use case  A user of the system can play more than one role  Example: A customer of the bank can be o A Borrower or o A Lender  Conversely, one actor can be a participant in multiple use cases  Example: A Borrower may be an actor in o The Borrow Money use case; o The Pay Interest on Loan use case; and o The Repay Loan Principal use case  Also, the actor Borrower may stand for many thousands of bank customers  An actor need not be a human being  Example: The Cardholder Clothing Company information system has to interact with the credit card company information system o The credit card company information system is an actor from the viewpoint of the Cardholder Clothing Company information system o The Cardholder Clothing Company information system is an actor from the viewpoint of the credit card company information system  A potential problem when identifying actors o Overlapping actors  Example: Hospital Information System o One use case has actor Nurse o A different use case has actor Medical Staff o Better: Actors: Physician and Nurse  Alternatively: o Actor Medical Staff with two specializations: Physician and Nurse

4

A. John Blesswin [101922]

2.4 REQUIREMENTS WORKFLOW- OSBERT OGLESBY CASE STUDY 2.4.1 INIT. BUSINESS MODEL  Osbert wants an information system, running on his laptop computer, that will o Determine the maximum price he should pay for a painting o Detect new trends in the art market as soon as possible  To do this, the information system needs to keep a record of all purchases and all sales  Currently, Osbert produces reports of annual sales and purchases by hand o At only a small additional cost, the information system can also print these two reports on demand  Osbert wants an information system that can o Compute the highest price he should pay for a painting; and o Detect new art trends  Osbert needs an information system that can also o Provide reports on purchases and sales  It is vital to determine the client’s needs up front, and not after the information system has been delivered  Osbert has three business activities: o He buys paintings o He sells paintings o He produces reports  Buy a Painting use case

 Sell a Painting use case

 Produce a Report use case

5

A. John Blesswin [101922]

 For conciseness, all three use cases are combined into a use-case diagram

 The only person who uses the current (manual) information system is Osbert o Osbert is therefore an actor in all three use cases  The customer may initiate the Buy a Painting or the Sell a Painting use case  The customer plays a critical part in both use cases by providing data entered information system by Osbert o The customer is therefore an actor in both these use cases  Next, the use cases have to be annotated  Here are the initial use-case descriptions

into the

 Buy a Painting use case

 Sell a Painting use case

6

A. John Blesswin [101922]

 Produce a Report use case

2.4.2 INITIAL REQUIREMENTS  The initial requirements are based on the initial business model  Then they are refined  The requirements are dynamic—there are frequent changes o Maintain a list of likely requirements, together with use cases of requirements approved by the client  There are two categories of requirements  A functional requirement specifies an action that the information system must be able to perform o Often expressed in terms of inputs and outputs  A nonfunctional requirement specifies properties of the information system itself, such as o Platform constraints o Response times o Reliability  Functional requirements are handled as part of the requirements and analysis workflows  Some nonfunctional requirements have to wait until the design workflow O The detailed information for some nonfunctional requirements is not available until the requirements and analysis workflows have been completed Initial Requirements: Osbert Oglesby Case Study  The initial business model (the three use cases) shows how Osbert currently does business  Decide which of these use cases are also requirements of the information system to be built o Clearly, all three are requirements  Refine the resulting initial requirements o The descriptions of the use cases have to be refined  Buy a Painting use case

7

A. John Blesswin [101922]

 Sell a Painting use case

 Produce a Report use case

 All three descriptions are still vague o A consequence of the iterative nature of the Unified Process o For example, the algorithm details are irrelevant at this time  Basic principle: Defer all details to as late as possible o This will simplify the inevitable changes of the next iteration  More details of each use case are needed now  First consider use cases o Buy a Painting, and o Sell a Painting  To refine the descriptions, determine what attributes need to be input when a painting is bought and when a painting is sold 2.4.3 ATTRIBUTES: OSBERT OGLESBY CASE STUDY (OR) CONTINUING THE REQUIREMENT WORKFLOW  Attributes when buying a painting include: o Title of work, name of artist, date of painting, classification, medium, purchase price, name and address of seller  Attributes when selling a painting are: o Date of sale, name of buyer, address of buyer, actual selling price  Now the algorithm for computing the maximum purchase price is considered  Classify the painting as a o Masterpiece 8

A. John Blesswin [101922]

o Masterwork, or o Other painting Maximum Price for a Masterpiece  Scan worldwide auction records over the past 25 years for the most similar work by the same artist  Use the auction purchase price of the most similar work as the base price  The maximum purchase price is found by adding 7.5 percent to the base price, compounded annually, for each year since that auction  Compute the maximum purchase price as if the painting were a masterpiece by the same artist  If the picture was painted in the 21st century, multiply this figure by 0.25  Otherwise, multiply it by (21 - c) / (22 - c), where c is the century in which the work was painted (12 < c < 21)  Measure the dimensions of the canvas  The maximum purchase price is then given by the formula F A, where o F is a constant for that artist (fashionability coefficient), and o A is the area of the canvas in square centimeters  If there is no fashionability coefficient for that artist, Osbert will not buy the painting Coefficient of Similarity: Osbert Oglesby  For a masterpiece or masterwork, the coefficient of similarity between two paintings is computed as follows: o Score 1 for a match on medium, otherwise 0 o Score 1 for a match on subject, otherwise 0 o Add these two numbers, multiply by the area of the smaller painting, and divide by the area of the larger o The resulting number is the coefficient of similarity  If the coefficient of similarity between the painting under consideration and all the paintings in the file of auction data is zero, then Osbert will not buy that masterwork or masterpiece Fashionability Coefficients: Osbert Oglesby  The information system must include a list of artists and their corresponding F values  The value of F can vary from month to month, depending on the current fashionability of an artist  Osbert determines the value of F on the basis of his knowledge and experience o He changes the value if prices for work by an artist increase or decrease Auction Data: Osbert Oglesby Case Study  The information system must utilize information on auction sales of masterpieces over the past 25 years worldwide  Each month Osbert receives a CD with updated worldwide auction prices; these prices are never modified by Osbert

9

A. John Blesswin [101922]

Updated Use Cases : Osbert Oglesby Case Study  The use-case descriptions must reflect this information  The description of the Sell a Painting use case:

Reports for the Osbert Oglesby Case Study  There are three reports: o Purchases during the past year o Sales during the past year o Detection of new trends  Sample reports show Osbert’s needs are as follows (question marks in the first or last name of artist, or in the title or date of the work are to be included in all reports): Report of Purchases during the Past Year  A report is needed to display all the paintings purchased during the past year o The average ratio of the purchase price to the suggested maximum price is required at the end of the report

10

A. John Blesswin [101922]

Report of Sales during the Past Year  A report is needed to display all the paintings sold during the past year o The average ratio of the actual selling price to the target selling price is required at the end of the report

Report of Trends during the Past Year  A report showing artists whose works Osbert has sold at a price that has exceeded the target selling price in every instance during the past year o To appear in this report, at least two of the artist’s works must have been sold by Osbert during that period

11

A. John Blesswin [101922]

2.4.4 UPDATED USE-CASE DESCRIPTION: PRODUCE A REPORT  The updated description of the Produce a Report use case, incorporating the details are listed below

Second Iteration of Use-Case Diagram  Incorporate all four use cases

Analysis of Req. Workflow: Osbert Oglesby  A fault was detected o There was a missing use case o The existing artifacts did not need to be changed  Two additional artifacts had to be added o A use case, and o Its description  The Unified Process is iterative and incremental o Systems analysts must always be aware that changes and extensions to the current version of the information system may have to made at any time 12

A. John Blesswin [101922]

2.5 MSG FOUNDATION CASE STUDY-REVISING THE REQUIREMENTS MARTHA STOCKTON GREENGAGE FOUNDATION  MSG provides low cost mortgage loans to young couples  Died at 87 & left behind $2billion  Trustees commission a pilot project o A software product to determine how much money is purchase homes

available each week to

Initial Understanding of the Domain  A mortgage is a loan in which real estate is used as security  Example: House costs $100,000  Buyer pays a 10% deposit and borrows the balance o The principal (or capital) borrowed is $90,000  Loan is to be repaid monthly over 30 years o Interest rate of 7.5% per annum (or 0.625% per month)  Each month, the borrower pays $629.30 o Part of this is the interest on the outstanding balance o The rest is used to reduce the principal  The monthly payment is therefore often referred to as P & I (principal and interest) Mortgage Payments: First Month  In the first month the outstanding balance is $90,000 o Monthly interest at 0.625% on $90,000 is $562.50 o The remainder of the P & I payment of $629.30, namely $66.80, is used to reduce the principal  At the end of the first month, after the first payment has been made, only $89,933.20 is owed to the finance company Mortgage Payments: Second Month  In the second month the outstanding balance is $89,933.20 o Monthly interest at 0.625% on $89,933.20 is $562.08 o The remainder of the P & I payment of $629.30, namely $67.22, is used to reduce the principal  At the end of the second month, after the second payment has been made, only $89,865.98 is owed to the finance company Mortgage Payments: After 15 and 30 yrs  After 15 years (180 months) the outstanding balance is $67,881.61 o Monthly interest at 0.625% on $67,881.61 is $424.26 o The remainder of the P & I payment of $629.30, namely $205.04, is used to reduce the principal  After 30 years (360 months), the entire loan will have been repaid

13

A. John Blesswin [101922]

Insurance Premiums  The finance company requires the borrower to insure the house o If the house burns down, the check from the insurance company will then be used to repay the loan  The insurance premium is paid once a year by the finance company o The finance company requires the borrower to pay monthly insurance installments o These are deposited in an escrow account (a savings account)  The annual premium is then paid from the escrow account Real Estate Taxes  Real-estate taxes paid on a home are treated the same way as insurance premiums o Monthly installments are deposited in the escrow account o The annual real-estate tax payment is made from that account Borrowing Limits  A mortgage will not be granted unless the total monthly payment (P & I plus insurance plus real-estate taxes) is less than 28% of the borrower’s total income Other Costs  The finance company requires a lump sum up front in return for lending the money to the borrower o Typically, the finance company will want 2% of the principal (“2 points”) o For the $90,000 loan, this amounts to $1,800  There are other costs involved in buying a house o Legal costs o Various taxes  When the deal is “closed,” the closing costs (legal costs, taxes, and so on) plus the points can easily amount to $7,000

14

A. John Blesswin [101922]

Initial Glossary

Initial Business Model  At the start of each week, MSG estimates how much money will be available that week to fund mortgages  Low-income couples can apply at any time  An MSG Foundation staff member determines o Whether the couple qualifies for an MSG mortgage, and o Whether MSG has sufficient funds on hand to purchase the home  If so, the mortgage is granted o The weekly mortgage repayment is computed according to MSG rules  This repayment amount may vary from week to week, depending on the couple’s current income  There are three use cases o Estimate Funds Available for Week o Apply for an MSG Mortgage o Compute Weekly Repayment Amount

15

A. John Blesswin [101922]

ESTIMATE FUNDS AVAILABLE FOR WEEK USE CASE

APPLY FOR AN MSG MORTGAGE USE CASE

16

A. John Blesswin [101922]

COMPUTE WEEKLY REPAYMENT AMOUNT USE CASE

Who Is an Actor?  Why is Applicants an actor in use case Apply for an MSG Mortgage?  Applicants do not interact with the software product o Their answers are entered into the software product by an MSG staff member  However, o The applicants initiate the use case o The applicants provide the data entered by MSG staff o The real actor is therefore Applicants — the MSG Staff Member is merely an agent of the applicants  Applicants is therefore indeed an actor  Similarly, Borrowers is an actor in use case Compute Weekly Repayment Amount o Again the use case is initiated by actor Borrowers o Again the information entered by MSG staff is supplied by the borrowers  Thus, Borrowers is indeed an actor in the use case MANAGE AN INVESTMENT USE CASE  At this stage, no details are known regarding o The buying and selling of investments, or o How investment income becomes available for mortgages  However, use case Manage an Investment is an essential part of the initial business model

17

A. John Blesswin [101922]

USE-CASE DIAGRAM OF THE INITIAL BUSINESS MODEL

18

A. John Blesswin [101922]

INITIAL REQUIREMENTS  It is unclear if all four use cases are all requirements of the product to be developed o What, exactly, is “a pilot project”?  The best way to proceed is o Draw up the initial requirements on the basis of what the client wants, and then iterate  Consider each use case in turn:  Estimate Funds Available for Week is obviously part of the initial requirements  Apply for an MSG Mortgage does not seem to have anything to do with the pilot project, so it is excluded  Compute Weekly Repayment Amount, & Manage an Investment o Both appear to be irrelevant to the pilot project  However, the pilot project deals with the “money that is available each week to purchase homes” o Some of that money comes from the weekly repayment of existing mortgages, and from income from investments INITIAL USE-CASE DIAGRAM

 The next step: Iterate the requirements workflow

19

A. John Blesswin [101922]

2.6 MSG - CONTINUING THE REQUIREMENTS WORKFLOW  The systems analysts learn that the MSG Foundation grants a 100% mortgage to buy a home under the following conditions: o The couple has been legally married for at least 1 year but not more than 10 years o Both husband and wife are gainfully employed o The price of the home must be below the published median price for homes in that area for the past 12 months o Their income and/or savings are insufficient to afford a standard fixed-rate 30year 90% mortgage o The foundation has sufficient funds to purchase the home  If the application is approved, then each week for the next 30 years the couple pays MSG o The total of the principal and interest payment — this never changes over the life of the mortgage; plus o The escrow payment, which is 1/52nd of the sum of the annual real-estate tax and the annual homeowner’s insurance premium  If this exceeds 28% of the couple’s gross weekly income, MSG pays the difference as a grant o The couple must provide proof of their current income — the weekly payment may vary from week to week Algorithm to Determine If Funds Are Available 1. At the beginning of the week, the estimated annual income from MSG investments is computed and divided by 52 2. The estimated annual MSG operating expenses are divided by 52 3. The total of the estimated mortgage payments for the week is computed 4. The total of the estimated grants for the week is computed 5. The amount available at the beginning of the week is then (1) - (2) + (3) - (4) 6. If the cost of the home is no more than (5), funds are provided to buy the home 7. At the end of each week, any unspent funds are invested Requirements of the Pilot Project  To keep the cost of the pilot project as low as possible, only those data items needed for the weekly funds computation will be included  Only three types of data are therefore needed: o Investment data o Operating expenses data o Mortgage data o Investment Data  Item number  Item name  Estimated annual return  Date estimated annual return was last updated

20

A. John Blesswin [101922]

o Operating Expenses Data  Estimated annual operating expenses  Date estimated annual operating expenses was last updated o Mortgage Data  Account number  Last name of mortgagees  Original purchase price of home  Date mortgage was issued  Weekly principal and interest payment  Current combined gross weekly income  Date combined gross weekly income was last updated  Annual real-estate tax  Date annual real-estate tax was last updated  Annual homeowner’s insurance premium  Date annual homeowner’s insurance premium was last updated Reports Required for the Pilot Project  Three types of reports are needed: o The results of the funds computation for the week o A listing of all investments (to be printed on request) o A listing of all mortgages (to be printed on request) Revising the Requirements  The initial requirements include three use cases: o Estimate Funds Available for Week o Compute Weekly Repayment Amount o Manage an Investment  In the light of the additional information received, the initial requirements can be revised  Consider each element of the formula to determine how much money is available each week (1) Estimated annual income from investments: o Take all the investments, sum the estimated annual return on each investment, and divide the result by 52  An additional use case, Estimate Investment Income for Week, is needed o (We still need use case Manage an Investment for adding, deleting, and modifying investments)

21

A. John Blesswin [101922]

Estimate investment income for week use case

Description of use case

FIRST ITERATION OF THE REVISED USE-CASE DIAGRAM

(2) Estimated annual operating expenses: To determine the estimated annual operating expenses two additional use cases are needed - Use case Update Estimated Annual Operating Expenses models adjustments to the value of the estimated annual operating expenses - Use case Estimate Operating Expenses for Week provides the needed estimate of the operating expenses

22

A. John Blesswin [101922]

Update Estimated Annual Operating Expenses Use Case

Estimate Operating Expenses for Week Use Case

23

A. John Blesswin [101922]

SECOND ITERATION OF REVISED USE-CASE DIAGRAM •

The new use cases are shaded

2.7 MSG FOUNDATION CASE STUDY-REFINING THE REVISED REQUIREMENTS  Total estimated mortgage payments for the week and Total estimated grant payments for the week: o Use case Compute Weekly Repayment Amount models the computation of both the estimated mortgage payment and the estimated grant payment for each mortgage separately o Summing these separate quantities gives The total estimated mortgage payments for the week, and The total estimated grant payments for the week  Now the use cases need to be reorganized o Use case Compute Weekly Repayment Amount also models borrowers updating their weekly income  Split Compute Weekly Repayment Amount into two separate use cases o Use case Estimate Payments and Grants for Week, and o Use case Update Borrowers’ Weekly Income

24

A. John Blesswin [101922]

Estimate Payments and Grants for Week Use Case

Estimate Payments and Grants for Week Use Case

Update Borrowers’ Weekly Income Use Case

25

A. John Blesswin [101922]

Third Iteration of the Revised Use-Case Diagram

Estimate Funds Available for Week Use Case •

Use case Estimate Funds Available for Week models the computation that uses the data obtained from three other use cases - Estimate Investment Income for Week – Estimate Operating Expenses for Week – Estimate Payments and Grants for Week

26

A. John Blesswin [101922]

Estimate Funds Available for Week Use Case

«include» Relationship  Correct use case (top); incorrect use case (bottom)

27

A. John Blesswin [101922]

 The bottom diagram models use cases o Estimate Funds Available for Week, and o Estimate Payments and Grants for Week o as two independent use cases o However, a use case models an interaction between the product itself and users of the product (actors)  Use case Estimate Payments and Grants for Week does not interact with an actor and therefore cannot be a use case in its own right o Instead, it is a portion of use case Estimate Funds Available for Week, as reflected in the top diagram The Test Workflow - (Refining the revised requirements)  A common side-effect of the iterative and incremental life-cycle model o Details that correctly have been postponed somehow get forgotten  Details of use case Manage an Investment have been overlooked, and  Use case Manage a Mortgage to model o The addition of a new mortgage o The modification of an existing mortgage, or o The removal of an existing mortgage o has been totally forgotten o (Analogous to use case Manage an Investment)  Manage a Mortgage Use Case

28

A. John Blesswin [101922]

Fourth Iteration of the Revised Use-Case Diagram

 There is a further omission o Use case Produce a Report to print the three reports Investments report Mortgages report Results of weekly computation o has also been totally forgotten

29

A. John Blesswin [101922]

 Produce a Report Use Case

30

A. John Blesswin [101922]

Fifth Iteration of the Revised Use-Case Diagram

 Rechecking the revised requirements uncovers two new problems o A use case has been partially duplicated o Two of the use cases need to be reorganized  Partially Duplicated Use Case  Use case Manage a Mortgage o One action is to modify a mortgage  Use case Update Borrowers’ Weekly Income o Only action is to update the borrowers’ weekly income  The borrowers’ weekly income is an attribute of the mortgage o Use case Manage a Mortgage already includes use case Update Borrowers’ Weekly Income 31

A. John Blesswin [101922]

 Accordingly, use case Update Borrowers’ Weekly Income is superfluous, and must be deleted Sixth Iteration of the Revised Use-Case Diagram

 This iteration resulted in a decrement, not an increment  In fact, deletion occurs often o Whenever we make a mistake  Sometimes we can fix an incorrect artifact o More frequently we have to delete an artifact  However, when we discover a fault, we do not have to start the whole process from scratch  First we try to fix the current iteration  If the mistake is too serious for this to work, we backtrack to the previous iteration, and try to find a better way to go forward from there  Reorganizing Two Use Cases  Determine the funds available for the current week o Use case Estimate Funds Available for Week models performing the calculation o Step 1.3 of use case Produce a Report models printing out the result of the computation  There is no point in estimating the funds available unless the results are printed out  The descriptions of the use cases 32

A. John Blesswin [101922]

o Estimate Funds Available for Week, and o Produce a Report o have to be modified (the use cases do not change)  Modified Description — Produce a Report

33

A. John Blesswin [101922]

 Modified Description — Estimate Funds Available for Week

 The usual reason for an «include» relationship is where one use case is part of two or more other use cases o Example: U.S. tax forms—avoiding triplication o

34

A. John Blesswin [101922]

 Seventh Iteration of Revised Use-Case Diagram

A. John Blesswin [101922]

Unit-3 OBJECT ORIENTED ANALYSIS SYLLABUS: Extracting entity classes -Initial dynamic model-Extracting control classes-refining use cases Incrementing the class diagram-Initial dynamic model-MSG Foundation case study revising the entity classes-Extracting-USE case realization-MSG Foundation case study incrementing the class diagrammore on use cases- risk INTRODUCTION  To obtain a deeper understanding of the requirements  To describe the requirements in a way that is o Easy to maintain, and o Provides insights into the structure of the target information system  Classes  The three class types in the Unified Process are o Entity classes o Boundary classes o Control classes UML notation

Entity Classes  An entity class models information that is long lived  Examples: o Account Class in a banking information system o Painting Class in the Osbert Oglesby information system o Mortgage Class and Investment Class in the MSG Foundation information system  Instances of all these classes remain in the information system for years Boundary Classes  A boundary class models the interaction between the information system and its actors  Boundary classes are generally associated with input and output  Examples: - Purchases Report Class and Sales Report Class in the Osbert Oglesby information system 1

A. John Blesswin [101922]

-

Mortgage Listing Class and Investment Listing Class in the MSG Foundation information system

Control Classes  A control class models complex computations and algorithms  Examples: o Compute Masterpiece Price Class, o Compute Masterwork Price Class, and o Compute Other Painting Price Class in the Osbert Oglesby information system 3.1 EXTRACTING ENTITY CLASSES  Entity class extraction consists of three steps that are carried out iteratively and incrementally: o Functional modeling Present scenarios of all the use cases (a scenario is an instance of a use case) o Class modeling Determine the entity classes and their attributes Determine the interrelationships and interactions between the entity classes Present this information in the form of a class diagram o Dynamic modeling Determine the operations performed by or to each entity class Present this information in the form of a statechart  Flowchart for Extracting Entity Classes

2

A. John Blesswin [101922]

3.1.1 Initial Functional Model: Osbert Oglesby  Recall the Osbert Oglesby use-case diagram:

 Use Case and Scenario  A use case depicts all possible interactions of a specific kind  A scenario is an instance of a use case o (Just as an object is an instance of a class) Scenario of Use Case Buy a Painting

 This is a normal scenario  There are six paragraphs in the scenario o Only four of them are numbered o The two unnumbered sentences “Osbert wishes to buy a masterpiece” and “Osbert makes an offer below the maximum purchase price—the offer is accepted by the seller” have nothing to do with the interaction between Osbert and the information system o These unnumbered paragraphs are essentially comments

3

A. John Blesswin [101922]

Second Scenario of Use Case Buy a Painting  This is an exception scenario o It models an interaction that is not

“normal”

Third Scenario of Use Case Buy a Painting  This is another exception scenario

Normal and Exception Scenarios  Normal and exception scenarios can be combined into an extended scenario

4

A. John Blesswin [101922]

 The systems analysis team investigates as many normal and exception scenarios of each use case as time permits o To get the deepest possible understanding of The domain The business model, and The use cases 3.1.2 Initial Class Diagram : Osbert Oglesby Case Study  The second step in extracting the entity classes is class modeling o The aim of this step is to extract the entity classes, determine their interrelationships, and find their attributes  Usually, the best way to begin this step is to use the two-stage noun extraction method o Stage 1: Describe the information system in a single paragraph o Stage 2: Identify the nouns in this paragraph, then select the entity classes from those nouns Noun Extraction: Osbert Oglesby Case Study  Stage 1: Describe the information system in one paragraph: o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings  Stage 2: Identify the nouns in this paragraph o Reports are to be generated in order to improve the effectiveness of the decisionmaking process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings  The nouns are report, effectiveness, process, buying, work of art, selling, information, painting, masterpiece, and masterwork  effectiveness, process and information are abstract nouns and are therefore unlikely to be entity classes o Abstract nouns identify things that have no physical existence  Nouns buying and selling are derived from the verbs “buy” and “sell” o They will probably be operations of some class  Noun report is unlikely to be an entity class, because a report is not long lived o A report is much more likely to be a boundary class  Noun work of art is just a synonym for painting First Iteration of the Initial Class Diagram  This leaves four candidate entity classes: o Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class

5

A. John Blesswin [101922]

Second Iteration of the Initial Class Diagram  Consider the interrelationships between the entity classes  A masterpiece is a specific type of painting, and so is a masterwork and an “other painting” o Painting Class is therefore the base class o Masterpiece Class, Masterwork Class, and Other Painting Class are subclasses of that base class

Third Iteration of the Initial Class Diagram  The class diagram does not reflect aspects of the pricing algorithm  When dealing with a masterwork o “The information system first computes the maximum purchase price as if it were a masterpiece by the same artist”  That is, a masterwork has to have all the attributes of a masterpiece (so that its maximum purchase price can be computed as if it were a masterpiece) and, in addition, it may have attributes of its own

Fourth Iteration of the Initial Class Diagram  Another aspect of the pricing algorithm that is not reflected in the current class diagram is o “The information system computes the coefficient of similarity between each painting for which there is an auction record and the painting under consideration for purchase” 6

A. John Blesswin [101922]

 Auctioned Painting Class is needed to make these comparisons o An auctioned painting must be a subclass of Painting Class o But a painting previously been sold at an auction somewhere in the world has nothing to do with paintings currently on display for sale in Osbert’s gallery

 An instance of Painting Class is either o A painting that Osbert has bought (an instance of Gallery Painting Class), or o A painting sold at some auction (an instance of Auctioned Painting Class) Fifth Iteration of the Initial Class Diagram  A third aspect of the maximum price algorithm that has not yet been modeled is fashionability o “The information system computes the maximum purchase price from the formula F , where F is a constant for that artist (fashionability coefficient) …”  Fashionability Class is needed o A painting of Other Painting Class can then use the instance of Fashionability Class for that artist to compute the maximum price that Osbert should offer to pay

7

A. John Blesswin [101922]

 Finally, we add the attributes of each class to the class diagram o For the Osbert Oglesby case study, the result is shown on the next slide  The empty rectangle at the bottom of each box will later be filled with the operations of that class

 Osbert Oglesby Application Class will contain the operation that starts execution of the whole software product  the fifth iteration of the initial class diagram, without the attributes, but explicitly reflecting the stereotypes o All eight classes in that figure are entity classes  This is also a class diagram o A class diagram depicts classes and their interrelationships; attributes and operations are optional

8

A. John Blesswin [101922]

3.2 INITIAL DYNAMIC MODEL  Dynamic modeling is the third step in extracting the entity classes  A statechart is constructed that reflects all the operations performed by or to the software product  The operations are determined from the scenarios Initial state-chart

 The solid circle (top left) represents the initial state  The white circle with the small black circle inside (top right) represents the final state  States other than the initial and final states are represented by rectangles with rounded corners  The arrows represent transitions from state to state  In state Osbert Oglesby Event Loop, one of five events can occur: o buy painting selected o sell painting selected o print report selected o update fissionability selected o quit selected

9

A. John Blesswin [101922]

Initial Main Menu: Osbert Oglesby  Graphical user interface (GUI) o “Point and click”

 In the object-oriented paradigm, there is a dynamic model for each class, rather than for the system as a whole, as in this case study o However, objects in this software product never move from one class to another class  Accordingly, a dynamic model for the software product as a whole is appropriate 3.3 EXTRACTING CONTROL CLASSES  It is also usually easy to extract control classes o Each nontrivial computation is generally modeled by a control class  In the case study there are four computations o Determining the maximum price that Osbert should offer for a Masterpiece Masterwork, or Other painting o Determining if there is a new trend in art purchases Initial Control Classes: Osbert Oglesby  There are therefore four initial control classes

10

A. John Blesswin [101922]

3.4 REFINING USE CASES  The pricing algorithm treats the three types of paintings differently  Use case Buy a Painting must therefore be refined into three separate use cases o Buy a Masterpiece o Buy a Masterwork o Buy Other Painting  Use case Produce a Report also needs to be refined o The purchases report and the sales report use simple data extraction — the future trends report involves computation o All three reports use their own boundary classes  For both these reasons, the Produce a Report use case must be refined into three use cases o Produce a Purchases Report o Produce a Sales Report o Produce a Future Trends Report Third Iteration of the Use-Case Diagram

 Implications for the remaining UML diagrams include: o The description of the new Buy a Painting use case (see over) must be split into three separate descriptions o The description of the Produce a Report use case must be split into three separate descriptions Use Case Buy a Masterpiece

11

A. John Blesswin [101922]

Description of Use Case Buy a Masterpiece

 The verb “The process of extending and refining use cases is called use-case realization” “realize” is used at least 3 different ways: o Understand (“Harvey slowly began to realize that he was in the wrong classroom”); o Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and o Accomplish (“Janet hopes to realize her dream of starting a computer company”)  In the phrase “realize a use case,” the word “realize” is used in this last sense  The realization of a specific scenario of a use case is depicted using an interaction diagram o Either a sequence diagram or collaboration diagram  Consider use case Buy a Masterpiece  We have previously seen o The use case o The description of the use case 12

A. John Blesswin [101922]

Buy a Masterpiece Use Case

The Four Classes That Enter into This Use Case  User Interface Class o This class models the user interface  Compute Masterpiece Price Class o This class models the computation of the price Osbert should offer  Masterpiece Class o The computation involves comparing the masterpiece being considered with masterpieces that have been previously auctioned  Auctioned Painting Class o These masterpieces are all instances of Auctioned Painting Class

the

Buy a Masterpiece Use Case  The Seller does not interact directly with the software product o Instead, the Seller provides data that Osbert enters into the software product  This is indicated in the note (the rectangle with the top right-hand corner turned over) o There is a dashed line from the note to the item to which it refers, the Seller in this case Scenario (one possible instance of the use case)

13

A. John Blesswin [101922]

 An executing software product uses objects, not classes  Example: o A specific masterpiece is not represented by Masterpiece Class but rather by an object, a specific instance of Masterpiece Class  Such an object is denoted in UML by : Masterpiece Class  A class diagram shows the classes in the use case and their relationships o It does not show the objects nor the sequence of messages as they are sent from object to object  Something more is needed  A collaboration diagram (of the realization of the scenario of the use case)

 Osbert will not approve the specification document unless he understands it  Accordingly, a written description of the collaboration diagram is needed o The flow of events  The flow of events of the collaboration diagram of the realization of the scenario of the use case  Osbert will not approve the specification document unless he understands it  Accordingly, a written description of the collaboration diagram is needed o The flow of events

 UML supports two different types of interaction diagram  Collaboration diagram  Sequence diagram  Both contain exactly the same information, but displayed in different ways 14

A. John Blesswin [101922]

 Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case)

 The narrow rectangle on a lifeline (dashed vertical line) shows when the relevant object is active  In the collaboration diagram, the [new] is inside the : Masterpiece Class object o In the sequence diagram, the object is shifted down so that its lifeline starts where the object is created  The sequence diagram shows that every message of the scenario involves either o The instance of the user interface class : User Interface Class or o The instance of the control class : Compute Masterpiece Price Class  It also shows that every transfer of information from object A to object B is eventually followed by a transfer in the reverse direction  These two facts are also true in the fully equivalent collaboration diagram, but are not as obvious in that format  It also shows that every transfer of information from object A to object B is eventually followed by a transfer in the reverse direction  These two facts are also true in the fully equivalent collaboration diagram, but are not as obvious in that format Interaction Diagrams  Software engineers can choose whether to use o A sequence diagram, or o A collaboration diagram, or o Both for each scenario  The strength of a sequence diagram is that it shows the flow of messages and their order unambiguously  When transfer of information is the focus of attention, a sequence diagram is superior to a collaboration diagram

15

A. John Blesswin [101922]

 A collaboration diagram is similar to a class diagram  When the developers are concentrating on the classes, a collaboration diagram is more useful than the equivalent sequence diagram  The seven previous figures depict different aspects of the use case Buy a Masterpiece  They use different notations and provide different levels of detail of the same activity  Why do we construct so many related artifacts?  We examine this one activity from a variety of different perspectives to learn enough about it to ensure that the analysis workflow will be correct  The maximum price of a masterwork is computed by first treating the painting as if it were a masterpiece, and then adjusting the result The Five Classes That Enter into This Use Case  User Interface Class  Compute Masterwork Price Class  This class models the computation of the price Osbert should offer  It creates a masterwork object and passes it to Compute Masterpiece Price Class as if it were a masterpiece  Compute Masterpiece Price Class  Masterpiece Class  Auctioned Painting Class Class diagram (classes that enter into the use case)

One possible scenario of the use case

16

A. John Blesswin [101922]

Buy Other Painting Use Case

 Modifying the Main Menu. The main menu must reflect buying the three different types of painting explicitly  Buy a Painting must be replaced by o Buy a Masterpiece, o Buy a Masterwork, and o Buy Other Painting  The revised screen is generated by : User Interface Class

SELL A PAINTING USE CASE - CLASS DIAGRAM

17

A. John Blesswin [101922]

PRODUCE A PURCHASES REPORT USE CASE- CLASS DIAGRAM

PRODUCE A SALES REPORT USE CASE

PRODUCE A FUTURE TRENDS REPORT USE CASE

MODIFY A FASHIONABILITY COEFFICIENT USE CASE

18

A. John Blesswin [101922]

3.5 INCREMENTING THE CLASS DIAGRAM  In the course of realizing the various use cases o Interrelationships between classes become apparent  Accordingly, we now combine the realization class diagrams Combining the Realization Class Diagrams

 Sixth Iteration of the Class Diagrams

19

A. John Blesswin [101922]

3.6 INITIAL DYNAMIC MODEL - MSG  Dynamic modeling is the third step in extracting the entity classes  A statechart is constructed that reflects all the operations performed by or to the software product  The operations are determined from the scenarios

 The statechart reflects the operations of the complete MSG Foundation information system o The solid circle on the top left represents the initial state, the starting point of the statechart o The white circle containing the small black circle on the top right represents the final state o States other than the initial and final states are represented by rectangles with rounded corners o The arrows represent possible transitions from state to state  In state MSG Foundation Information System Loop, one of five events can occur  An MSG staff member can issue one of five commands: o estimate funds for the week o manage an asset o update estimated annual operating expenses o produce a report, or o quit  These possibilities are indicated by the five events o estimate funds for the week selected o manage an asset selected o update estimated annual operating expenses selected o produce a report selected, and o quit selected  An event causes a transition between states  An MSG staff member selects an option by clicking on the menu

20

A. John Blesswin [101922]

 This graphical user interface (GUI) requires special software  Equivalent textual user interface that can run on any computer

3.7 MSG FOUNDATION CASE STUDY REVISING THE ENTITY CLASSES  The initial functional model, the initial class diagram, and the initial dynamic model are completed o Checking them reveals a fault  In the initial statechart, consider state Update Estimated Annual Operating Expenses with operation Update the estimated annual operating expenses o This operation has to be performed on the current value of the estimated annual operating expense  But where is the value of the estimated annual operating expenses to be found?  Currently there is only one class (Asset Class) and its two subclasses o Neither is appropriate for storing the estimated annual operating expenses  The only way a value can be stored on a long-term basis is as an attribute of an instance of that class or its subclasses  Another entity class is needed for storing the estimated annual operating expenses o MSG Application Class Third Iteration of the Initial Class Diagram: MSG Foundation  MSG Application Class has other attributes as well o Attributes that do not appertain to the assets

21

A. John Blesswin [101922]

 The class diagram redrawn to show the prototypes

22

A. John Blesswin [101922]

Extracting the Boundary Classes: MSG Foundation  It is usually easy to extract boundary classes o Each input screen, output screen, and printed report is generally modeled by a boundary class o One screen should be adequate for all four MSG Foundation use cases Estimate Funds Available for Week Manage an Asset Update Estimated Annual Operating Expenses Produce a Report o Accordingly there is one initial boundary class o User Interface Class  Three reports have to be printed o The estimated funds for the week report o The listing of all mortgages o The listing of all investments  Each of these has to be modeled by a separate boundary class o Estimated Funds Report Class o Mortgages Report Class o Investments Report Class  Here are the four initial boundary classes

 There are three reports: o The purchases report o The sales report o The future trends report  The content of each report is different o Each report therefore has to be modeled by a separate boundary class 3.8 USE CASE REALIZATION : THE MSG FOUNDATION CASE STUDY  The process of extending and refining use cases is called use-case realization  The verb “realize” is used at least 3 different ways: o Understand (“Harvey slowly began to realize that he was in the wrong classroom”); o Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and o Accomplish (“Janet hopes to realize her dream of starting a computer company”)  In the phrase “realize a use case,” the word “realize” is used in this last sense  The realization of a specific scenario of a use case is depicted using an interaction diagram o Either a sequence diagram or collaboration diagram  Consider use case Estimate Funds Available for Week 23

A. John Blesswin [101922]

 We have previously seen o The use case o The description of the use case 3.8.1 Estimate Funds Available for Week Use Case  Use-case diagram

 Description of use case

24

A. John Blesswin [101922]

 Class diagram (classes that enter into the use case)

 The six classes that enter into this use case are: o User Interface Class This class models the user interface o Estimate Funds for Week Class This control class models the computation of the estimate of the funds that are available to fund mortgages during that week o Mortgage Class This class models the estimated grants and payments for the week o Investment Class This class models the estimated return on investments for the week o MSG Application Class This class models the estimated return on investments for the week o Estimated Funds Report Class This class models the printing of the report

25

A. John Blesswin [101922]

 Scenario (one possible instance of the use case)

 A working information system uses objects, not classes o Example: A specific mortgage cannot be represented by Mortgage Class but rather by an object, a specific instance of Mortgage Class  Such an object is denoted by : Mortgage Class  A class diagram shows the classes in the use case and their relationships o It does not show the objects nor the sequence of messages as they are sent from object to object

26

A. John Blesswin [101922]

 Collaboration diagram (of the realization of the scenario of the use case)

 The collaboration diagram shows the objects as well as the messages, numbered in the order in which they are sent in the specific scenario  Item 1: o The staff member wants to compute the funds available for the week o In the collaboration diagram, this is modeled by message 1: Request estimate of funds available for week  from MSG Staff Member to : User Interface Class, an instance of User Interface Class  Item 2 o This request is passed on to : Estimate Funds for Week Class, an instance of the control class that actually performs the calculation o This is modeled by message 2: Transfer request  Four separate financial estimates are now determined by : Estimate Funds for Week Class 27

A. John Blesswin [101922]

 Item 3 o In Step 1 of the scenario, the estimated annual return on investments is summed for each investment and the result divided by 52 o This extraction of the estimated weekly return is modeled by message  3: Request estimated return on investments for week from : Estimate Funds for Week Class to : Investment Class followed by message 4: Return estimated weekly return on investments in the other direction  Item 4 o In Step 2 of the scenario, the weekly operating expenses are estimated by taking the estimated annual operating expenses and dividing by 52 o This extraction of the weekly expenses is modeled by message 5: Request estimated operating expenses for week from : Estimate Funds for Week Class to : MSG Application Class followed by message 6: Return estimated operating expenses for week in the other direction  Item 5 o In Steps 3, 4, and 5 of the scenario, two estimates are determined the estimated grants for the week, and the estimated payments for the week o This is modeled by message 7: Request estimated grants and payments for week from : Estimate Funds for Week Class to : Mortgage Class, and by message 8: Return estimated grants and payments for week in the other direction  Item 6 o Now the arithmetic computation of Step 6 of the scenario is performed o This is modeled by message 9: Compute estimated amount available for week o This is a self call o : Estimate Funds for Week Class tells itself to perform the calculation o The result of the computation is stored in : MSG Application Class by message 10: Transfer estimated amount available for week  Item 7 o The result is printed in Step 7 of the scenario o This is modeled by message 11: Print estimated amount available o from : MSG Application Class to : Estimated Funds Report Class  Item 8 o Finally, an acknowledgment is sent to the MSG staff member that the task has been successfully completed o This is modeled by messages 12: Send successful completion message 13: Send successful completion message 14: Transfer successful completion message, and 15: Display successful completion message  No client will approve the specification document without understanding it

28

A. John Blesswin [101922]

 Accordingly, a written events

description of the collaboration diagram is needed, the flow of

 The flow of events of the collaboration diagram of the realization of the scenario of the use case

 Sequence diagram equivalent to the collaboration diagram (of the realization of the scenario of the use case) 3.9 MSG FOUNDATION CASE STUDY INCREMENTING THE CLASS DIAGRAM  In the course of realizing the various use cases o Interrelationships between classes become apparent  Accordingly, we now combine the realization class diagrams COMBINING THE REALIZATION CLASS DIAGRAMS

29

A. John Blesswin [101922]

FIFTH ITERATION + REALIZATION CLASS DIAGRAM

3.9.1

MANAGE AN ASSET USE CASE

 USE CASE

30

A. John Blesswin [101922]

DESCRIPTION OF USE CASE

CLASS DIAGRAM SHOWING THE CASE

CLASSES THAT REALIZE THE USE

ONE SCENARIO OF THE USE CASE

31

A. John Blesswin [101922]

COLLABORATION DIAGRAM OF THE REALIZATION OF THE SCENARIO OF THE USE CASE

 Object : Investment Class does not play an active role in this collaboration diagram o This scenario does not involve an investment, only a mortgage  Actor Borrowers does not play a role in this use case, either

32

A. John Blesswin [101922]

SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE)

A DIFFERENT SCENARIO OF THE USE CASE

 At the request of the borrowers, the MSG staff member updates the weekly income of a couple  The scenario is initiated by the Borrowers  Their data are entered into the software product by the MSG Staff Member o This is stated in the note in the collaboration diagram

33

A. John Blesswin [101922]

SEQUENCE DIAGRAM EQUIVALENT TO THE COLLABORATION DIAGRAM (OF THE REALIZATION OF THE SCENARIO OF THE USE CASE)

 Two different scenarios of the same use case have been presented  The use case is the same o The class diagram is therefore the same  However, the collaboration (and sequence) diagrams reflect the differences between two scenarios  Boundary class User Interface Class appears in all the realizations o The same screen will be used for all commands of the information system  Revised menu

the

34

A. John Blesswin [101922]

Corresponding textual interface

3.9.2 UPDATE ANNUAL OPERATING EXPENSES USE CASE Class diagram

Collaboration diagram of a realization of a scenario of the use case

35

A. John Blesswin [101922]

Equivalent sequence diagram

3.9.3 Produce a Report Use Case Use case

36

A. John Blesswin [101922]

Description of use case

Class diagram

37

A. John Blesswin [101922]

One scenario of the use case

Collaboration diagram  Mortgages (but not investments) are involved

38

A. John Blesswin [101922]

Sequence diagram

A second scenario (listing all investments) of the use case

39

A. John Blesswin [101922]

 Collaboration diagram for second scenario  This time, investments (but not mortgages) are involved

Sequence diagram for second scenario

40

A. John Blesswin [101922]

3.10 MORE ON USE CASES  In the Unified Process o The term worker is used to denote a role played by an individual o In the Unified Process, Applicants and Borrowers are two different workers  In common parlance o The word “worker” usually refers to an employee  Within a business context, finding the roles is easy o They are displayed within the use-case business model  To find the actors o Find the subset of the use-case business model that corresponds to the use-case model of the requirements  To find the actors (in more detail): o Construct the use-case business model o Consider only those parts of the business model that correspond to the proposed software product o The actors in this subset are the actors we seek  Within a business context, finding use cases is easy  For each role, there will be one or more use cases 3.11 RISK  A major risk in developing a new information system is that the delivered information system does not meet the client’s needs.  In the traditional paradigm, this risk was met by constructing rapid prototype, a hurriedly thrown together working program that displays the key functionality of the target information.  This type of information is not needed in the unified process, because the use cases and their scenarios take the place of the rapid prototype. 3.11.1 Rapid prototyping  Many approaches have been put forward for ensuring that the client’s needs are truly met by the specification document.  They all reduce to the systems analysts sitting down with the client, going through

the

specification document line by line and asking, “Are you really, really, really sure that this is what you want the proposed information system to do?” none of these methods are foolproof. 1st situation concerns Joe and Jane Johnson, who decide to build a house. They consult with an architect. Instead of showing them sketches, plans, perhaps a model, the architect gives them a 20 page, single-spaced document, describing the house in highly technical 41

A. John Blesswin [101922]

terms. Despite the fact that both Joe and Jane have no previous architectural experience and hardly understand any of the documents, they enthusiastically sign

it and say, “Go

right ahead; build the house!” 2nd situation concerns Mark Marberry, who buys his suits by mail order. Instead of mailing him pictures of their suits and samples of available cloths, the company sends Mark a catalog containing written description of the cut and the cloth of their products. Mark then order a suit solely based on the written description.  The client use the information system for a few minutes, then turns to the system analysts and says “I know that this is the information system I asked for, but it is not what I wanted”.  A rapid prototype

is a working program that exhibits the key behavior of that

information system. For example, if the target information system is to handle accounts payable, accounts receivable and warehousing, then the rapid prototype may consist of an information system that performs the screen handling for data capture and prints the reports, but does no database updating or error handling

(hidden aspects).

 The client and users then experiment with the prototype to determine whether it indeed meets their needs. The rapid prototype can be changed until the client and users are satisfied that it encapsulates the functionality they desire. Key points:  It must be “rapid”. That is it must be thrown together as quickly as possible. The use is to make sure, when the complete information system is delivered to the client a year or so later, the functionality of the system will be precisely what the client needs. One way of doing this is for the client to experiment with a computer program that behaves the same way the target information system will behave.  After the rapid prototype has been approved by the client, it must be thrown away without any sort of specification or design document. Making changes when there is no documentation of any kind is both expensive and foolhardy. 3.11.2 Scenarios and the Client’s needs  Instead of constructing

a rapid prototype, the use cases or more precisely, interaction

diagrams reflecting the classes that realize the scenarios of the use cases as shown to the client. The client can understand how the

target information system will behave just as 42

A. John Blesswin [101922]

well from the interaction diagrams and their written flow of events as from a rapid prototype. There is a need to construct specimen screens and reports, preferably with the aid of screen generators, report generators and CASE tools that

make it easy to produce the

code for screens and reports.

43

A. John Blesswin [101922]

Unit-4 OBJECT ORIENTED DESIGN WORKFLOW SYLLABUS: Design workflow-format of the attributes- allocation of operations- Osbert Oglesby case studyWorkflows of the unified process-Phases of the unified process- class diagrams-Use case diagrams- Interaction diagrams-state charts-package diagrams-Deployment diagrams. 4.1 DESIGN WORKFLOW  The input to the design workflow is the set of analysis workflow artifacts - These artifacts are iterated and incremented until they can be used by the programmers  A major aspect of this iteration and incrementation is - The identification of operations, and - Their allocation to the appropriate classes  Many other decisions have to be made as part of the design workflow, including - Choice of programming language - Deciding how much of existing information systems to reuse in the new information system - Level of portability - The allocation of each software component to its hardware component  The case studies in this book are small-scale information systems - Under 5,000 lines of Java or C++ code in length  The Unified Process was designed for developing large-scale information systems - 500,000 lines of code or more  During the analysis workflow, a large information system is partitioned into analysis packages - Each analysis package consists of a set of related classes that can be implemented as a single unit - Example: o Accounts payable, accounts receivable, and general ledger are typical analysis packages  The concept underlying analysis packages is: - It is easier to develop smaller information systems than larger information systems - A large information system will be easier to develop if it can be decomposed into independent packages  The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow  The objective is to break up the upcoming implementation workflow into manageable pieces - Subsystems

1

A. John Blesswin [101922]

 It does not make sense to break up the two case studies into subsystems—they are just too small  Reasons why subsystems are utilized - It is easier to implement a number of smaller subsystems than one large system – If the subsystems are independent, they can be implemented by programming teams working in parallel o The information system as a whole can then be delivered sooner  The architecture of an information system includes - The various component modules – How they fit together – The allocation of components to subsystems  The task of designing the architecture is specialized - It is performed by an information system architect  The architect needs to make trade-offs - Every information system must satisfy its functional requirements (the use cases) – It also must satisfy its nonfunctional requirements, including o Portability, reliability, robustness, maintainability, and security – It must do all these things within budget and within the time constraint  The architect must assist the client by laying out the trade-offs  It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints - Some sort of compromises have to be made  The client has to - Relax some of the requirements; – Increase the budget; and/or – Move the delivery deadline  The architecture of an information system is critical - The requirements workflow can be fixed during the analysis workflow – The analysis workflow can be fixed during the design workflow – The design workflow can be fixed during the implementation workflow  But there is no way to recover from suboptimal architecture - The architecture must immediately be redesigned 4.2 FORMAT OF THE ATTRIBUTES  As part of the design workflow, the exact format of each attribute of the class diagram must be specified - Example: A date is usually represented by 10 characters – For instance, December 3, 1947 is represented as o 12/03/1947 in the United States (MM/DD/YYYY format), and o 03/12/1947 in Europe (DD/MM/YYYY format) – For both date conventions, 10 characters are needed  The formats could be determined during the analysis workflow  However, the object-oriented paradigm is iterative - Information is added to models as late as possible 2

A. John Blesswin [101922]

 Adding an item too early will make the next iteration unnecessarily burdensome - Formats are therefore added during the design workflow

 Examples: - First name of an artist is up to 20 characters in length, optionally followed by ? if there is uncertainty o firstNameOfArtist : 21 chars – Title is up to 40 characters in length, optionally with ? o title : 41 chars – Height and width are measured in centimeters o height, width : 4 digits (up to 9999 centimeters, or 99.99 meters) – Prices o targetSellingPrice, actualSellingPrice, maxPurchasePrice : 8 digits (up to $99,999,999) - Dates o dateOfPurchase, dateOfSale, auctionDate : 10 chars  Fashionability coefficient - This could be a large number or a small number 3

A. John Blesswin [101922]

 The range can be determined only by computing coefficients from a sample of Osbert’s sales - High: 985 (Rembrandt van Rijn) – Low: 0.064 (Joey T. Dog)  For safety, coefficient is of type 4 + 4 digits  Range is - High: 9999.9999 – Low: 0.0001  Class diagram with the formats of attributes added

 Example: - An asset number consists of 12 characters o assetNumber : 12 digits – Annual operating expenses are up to $999,999,999.99 o estimatedAnnualOperatingExpenses : 9 + 2 digits 4.3 ALLOCATION OF OPERATIONS  First the initial class diagram is determined - Then the interaction diagrams of the realizations of the use cases  These interaction diagrams are used to deduce the operations 4

A. John Blesswin [101922]

- Only then can the operations be allocated to the classes  Identifying the operations to be allocated to the various classes is easy  Determining to which class each operation should be allocated is hard  Three criteria are used - Responsibility-driven design – Inheritance – Polymorphism and dynamic binding  Third iteration of the initial MSG class diagram

4.3.1 RESPONSIBILITY-DRIVEN DESIGN  The principle of responsibility-driven design o If Class A sends a message to Class B telling it to do something, it is the responsibility of Class B to perform the requested operation  Responsibility-Driven Design: MSG Case Study

5

A. John Blesswin [101922]

 The weekly return on investments is computed by summing the estimated annual return of each investment and dividing by 52 - The sequence diagram includes the message o 3: Request estimated return on investments for week  The MSG Foundation case study must therefore include the operation getAnnualReturnOnInvestment - Thus, for each object of class Investment Class, the estimated annual return on that investment can be determined  It is not important which class sends that message  What is important is that Investment Class has the responsibility of determining the annual return on an investment - Accordingly, operation getAnnualReturnOnInvestment must be allocated to Investment Class  Allocation of getAnnualReturnOnInvestment

6

A. John Blesswin [101922]

4.3.2 INHERITANCE  Suppose an operation is applicable to - An instance of a superclass; and to – Instances of subclasses of that superclass  Allocate that operation to the superclass  Then there is just one version of that operation  It can be used by - Instances of the superclass and by Instances of all its subclasses  Convention in an object-oriented information system - Associated with each attribute of a class are operations o setAttribute, used to assign a particular value to that attribute; and o getAttribute, which returns the current value of that attribute  Example: In the MSG case study every asset has an asset number - Asset Class has an attribute assetNumber o Operation setAssetNumber is used to assign the number of the asset to the object that represents that asset o Operation getAssetNumber is used to obtain the asset number of the asset represented by that object  To which class should operation setAssetNumber be allocated?  In the traditional paradigm, there would be two different versions of setAssetNumber, one for each of the two types of asset - That is, there would have to be o setInvestmentNumber o setMortgageNumber  Two separate functions are needed because the traditional paradigm does not support inheritance  In the object-oriented paradigm - Consider the MSG inheritance hierarchy

7

A. John Blesswin [101922]

 Asset Class has attribute assetNumber - Inherited by Investment Class and Mortgage Class – Thus o Every instance of class Investment Class, and o Every instance of class Mortgage Class has attribute assetNumber that consists of 12 characters  Any operation of class Asset Class that could be applied to attribute assetNumber - Can also be applied to attribute assetNumber of o Every instance of class Investment Class, and o Every instance of class Mortgage Class  Allocation of setAssetNumber, getAssetNumber

 Operation setAssetNumber can then be applied to instances of - Class Investment Class or – Class Mortgage Class  Allocation of Operations: Osbert Oglesby -

Fifth iteration of the initial class diagram

8

A. John Blesswin [101922]

4.4 OSBERT OGLESBY CASE STUDY 4.4.1 RESPONSIBILITY-DRIVEN DESIGN: OSBERT OGLESBY CASE STUDY –

Consider operation getAuctionPrice Irrespective of the source of the message requesting an auction price o Operation getAuctionPrice must be allocated to Auctioned Painting Class

-

Allocation of getAuctionPrice

9

A. John Blesswin [101922]

4.4.2 INHERITANCE: OSBERT OGLESBY CASE STUDY  Consider operations o setTitle and o getTitle  Example: Osbert prints a list of all his paintings o Each object in the information system in turn is examined o A message is sent to operation getTitle to obtain the title of the painting represented by that object  To which class must operations o setTitle and o getTitle be allocated?  First consider operation setTitle  In the traditional paradigm, there would have to be three different versions of setTitle, one for each type of painting o set_masterpiece_title o set_masterwork_title o set_other_painting_title  That is because the traditional paradigm does not support inheritance  In the object-oriented paradigm, consider the Painting Class inheritance hierarchy  Painting Class has attribute title o This attribute is inherited by instances of its 5 subclasses Gallery Painting Class Auctioned Painting Class Masterpiece Class Masterwork Class Other Painting Class  Thus, operation setTitle must be allocated to Painting Class so that it can be inherited (and used) by instances of all five subclasses  This applies to all operations, including getTitle  Allocation of operations setTitle and getTitle

A. John Blesswin [101922]

4.5 WORKFLOWS OF THE UNIFIED PROCESS  There are five core workflows - Requirements workflow – Analysis workflow – Design workflow – Implementation workflow – Test workflow  In each increment, part of each of these five workflows is carried out

 In addition to the five core workflows, the Unified Process includes other workflows - Management – Planning The Requirements Workflow  The aim of the requirements workflow - To ensure that the developers build the right information system The analysis workflow  The aim of the analysis workflow - To analyze and refine the requirements  Why not do this during the requirements workflow? - The requirements artifacts must be totally comprehensible by the client  The artifacts of the requirements workflow must therefore be expressed in a natural (human) language - All natural languages are imprecise  Example from a manufacturing information system: - “A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant” 11

A. John Blesswin [101922]

 To what does the it refer? - The part record? – The plant record? – Or the database?  Two separate workflows are needed - The requirements artifacts must be expressed in the language of the client – The analysis artifacts must be precise, and complete enough for the designers The Design Workflow  The aim of the design workflow is to refine the analysis workflow until the material is in a form that can be implemented by the programmers - Many nonfunctional requirements need to be finalized at this time, including » Choice of programming language » Reuse issues » Portability issues The Implementation Workflow  The aim of the implementation workflow is to implement the target information system in the selected implementation language - A large information system is partitioned into subsystems – The subsystems consist of components or code artifacts The Test Workflow  The test workflow is the responsibility of the quality assurance group - Each component is tested as it has been implemented o Unit testing – At the end of each iteration, the completed components are compiled and linked together (integrated) and tested o Integration testing – When the product appears to be complete, it is tested as a whole o Product testing – Once the completed product has been installed on the client’s computer, the client tests it o Acceptance testing 4.6 PHASES OF THE UNIFIED PROCESS  In the figure, the increments are identified as phases

12

A. John Blesswin [101922]

 The four increments are labeled o Inception phase o Elaboration phase o Construction phase o Transition phase  The phases of the Unified Process are the increments  In theory, there could be any number of increments o In practice, development seems to consist of four increments  Every step performed in the Unified Process falls into o One of the five core workflows and also o One of the four phases  Why does each step have to be considered twice?  Workflow o Presented in a technical context  Phase o Presented in a business context 4.6.1 The Inception Phase  The aim of the inception phase is to determine whether the proposed information system is economically viable 1. Gain an understanding of the domain 2. Build the business model 3. Delimit the scope of the proposed project o Focus on the subset of the business model that is covered /by the proposed information system 4. Begin to make the initial business case The Inception Phase : The Initial Business Case  Questions that need to be answered include: o Is the proposed information system cost effective? o How long will it take to obtain a return on investment? o Alternatively, what will be the cost if the company decides not to develop the proposed information system? o If the information system is to be sold in the marketplace, have the necessary marketing studies been performed? o Can the proposed information system be delivered in time? o If the information system is to be developed to support the client organization’s own activities, what will be the impact if the proposed information system is delivered late?  What are the risks involved in developing the information system, and  How can these risks be mitigated? o Does the team who will develop the proposed information system have the necessary experience? o Is new hardware needed for this information system 13

A. John Blesswin [101922]

o If so, is there a risk that it will not be delivered in time? o If so, is there a way to mitigate that risk, perhaps by ordering back-up hardware from another supplier? o Are software tools (Chapter 11) needed? o Are they currently available? o Do they have all the necessary functionality?  Answers are needed by the end of the inception phase so that the initial business case can be made The Inception Phase: Use Cases and Risks  The next step: o Identify the use cases o Prioritize them in the order of the risk that they carry  There are three major risk categories: o Technical risks o The risk of not getting the requirements right Mitigated by performing the requirements workflow correctly o The risk of not getting the architecture right The architecture may not be sufficiently robust  To mitigate all three classes of risks o The use cases need to be prioritized in order of associated risk so that the critical risks are mitigated first  This concludes the steps of the inception phase that fall under the requirements workflow The Inception Phase: Analysis, Design Workflows  A small amount of the analysis workflow may be performed during the inception phase  A few critical use cases are analyzed, so that the design of the architecture can begin  Thus, a small amount of the design workflow may be performed, too The Inception Phase: Implementation Workflow  Coding is generally not performed during the inception phase  Sometimes a proof-of-concept prototype is build to test the feasibility of part of the information system o This is not a rapid prototype constructed to be certain that the requirements have been accurately determined Rapid prototyping is not part of the Unified Process o A proof-of-concept prototype is more like an engineering prototype A scale model constructed to test the feasibility of construction The Inception Phase: Test Workflow  The test workflow commences almost at the start of the inception phase o The aim is to ensure that the requirements have been accurately determined 14

A. John Blesswin [101922]

The Inception Phase: Planning  There is insufficient information at the beginning of the inception phase to plan the entire development o The only planning that is done at the start of the project is the planning for the inception phase itself  For the same reason, the only planning that can be done at the end of the inception phase is the plan for just the next phase, the elaboration phase The Inception Phase: Documentation  The deliverables of the inception phase include: o The initial version of the domain model o The initial version of the business model o The initial version of the requirements artifact (especially the use cases) o A preliminary version of the analysis artifacts o A preliminary version of the architecture o The initial list of risks o The initial ordering of the use cases o The plan for the elaboration phase  The initial version of the business case The Inception Phase: The Initial Business Case  Obtaining the initial version of the business case is the overall aim of the inception phase  This initial version incorporates o A description of the scope of the information system o Financial details o If the proposed information system is to be marketed, the business case will also include Revenue projections, market estimates, initial cost estimates o If the information system is to be used in-house, the business case will include The initial cost-benefit analysis 4.6.2 The Elaboration Phase  The aim of the elaboration phase is to refine the initial requirements o Refine the use cases o Refine the architecture o Monitor the risks and refine their priorities o Refine the business case o Produce the project management plan  The major activities of the elaboration phase are refinements or elaborations of the previous phase

15

A. John Blesswin [101922]

The Tasks of the Elaboration Phase  The tasks of the elaboration phase correspond to: o All but completing the requirements workflow o Performing virtually the entire analysis workflow o Starting the design of the architecture The Elaboration Phase: Documentation  The deliverables of the elaboration phase include: o The completed domain model o The completed business model o The completed requirements artifacts o The completed analysis artifacts o An updated version of the architecture o An updated list of risks o The project management plan (for the rest of the project) o The completed business case 4.6.3

Construction Phase

 The aim of the construction phase is to produce the first operational-quality version of the information system o This is sometimes called the beta release  The Tasks of the Construction Phase  The emphasis in this phase is on o Implementation, and o Testing Unit testing of modules Integration testing of subsystems Product testing of the overall system The Construction Phase: Documentation  The deliverables of the construction phase include: o The initial user manual and other manuals, as appropriate o All the artifacts (beta release versions) o The completed architecture o The updated risk list o The project management plan (for the remainder of the project) o If necessary, the updated business case 4.6.4

The Transition Phase

 The aim of the transition phase is to ensure been met

that the client’s requirements have indeed

16

A. John Blesswin [101922]

o Faults in the information system are corrected o All the manuals are completed o Attempts are made to discover any previously unidentified risks  This phase is driven by feedback from the site(s) at which the beta release has been installed The Transition Phase: Documentation  The deliverables of the transition phase include: o All the artifacts (final versions) o The completed manuals 4.7 CLASS DIAGRAMS  A class diagram depicts classes and their interrelationships  Here is the simplest possible class diagram

 Class diagram showing more details of Bank Account Class

 Add as many (or as few) details as appropriate for the current iteration and incrementation Class Diagrams: Notation  Freedom of notation extends to objects  Example: o bank account : Bank Account Class  Bank account is an object, an instance of a class Bank Account Class o The underlining denotes an object o The colon denotes “an instance of” o The bold face and initial upper case letters in Bank Account Class denote that this is a class  UML allows a shorter notation when there is no ambiguity 17

A. John Blesswin [101922]

o bank account  The UML notation for modeling the concept of an arbitrary bank account is o : Bank Account Class  The colon means “an instance of,” so o : Bank Account Class means o “an instance of class Bank Account Class” Class Diagrams: Visibility Prefixes  UML visibility prefixes (used for information hiding) o Prefix + indicates that an attribute or operation is public Visible everywhere o Prefix - denotes that the attribute or operation is private Visible only in the class in which it is defined o Prefix # denotes that the attribute or operation is protected Visible either within the class in which it is defined or within subclasses of that class  Example: o Class diagram with visibility prefixes added

o Attribute accountBalance is visible only within the Bank Account Class o Operations deposit and withdraw are accessible from anywhere within the information system 4.7.1 AGGREGATION  Example: “A car consists of a chassis, an engine, wheels, and seats”

18

A. John Blesswin [101922]

 The open diamonds denote aggregation o Aggregation is the UML term for the part-whole relationship  The diamond is placed at the “whole” (car) end, not the “part” (chassis, engine, wheels, or seats) end of the line connecting a part to the whole 4.7.2 MULTIPLICITY  Example: “A car consists of one chassis, one engine, 4 or 5 wheels, an optional sun roof, zero or more fuzzy dice hanging from the rear-view mirror, and 2 or more seats”

 The numbers next to the ends of the lines denote multiplicity o The number of times that the one class is associated with the other class  Item 1: o The line connecting Chassis Class to Car Class The 1 at the “part” end of the line denotes that there is one chassis involved The 1 at the “whole” end denotes that there is one car involved o Each car has one chassis, as required o Similar observations hold for the line connecting Engine Class to Car Class  Item 2: o The line connecting Wheels Class to Car Class The 4..5 at the “part” end together with the 1 at the “whole” end denotes that each car has from 4 to 5 wheels (the fifth wheel is the spare) o A car has 4 or 5 wheels, as required Instances of classes come in whole numbers only  Item 3: o The line connecting Sun Roof Class to Car Class Two dots .. denote a range, so the 0..1 means zero or one, the UML way of denoting “optional” o A car has an optional sun roof, as required  Item 4: 19

A. John Blesswin [101922]

o The line connecting Fuzzy Dice Class to Car Class The * by itself means zero or more o Each car has zero or more fuzzy dice hanging from the rear-view mirror, as required  Item 5: o The line connecting Seats Class to Car Class An asterisk in a range denotes “or more,” so the 2..* means 2 or more o A car has two or more seats, as required  If the exact multiplicity is known, use it o Example: The 1 that appears in 8 places o If the range is known, use the range notation o Examples: 0..1 or 4..5 o If the number is unspecified, use the asterisk o Example: * o If the range has upper limit unspecified, combine the range notation with the asterisk notation o Example: 2..* 4.7.3

COMPOSITION

 Aggregation example: Every chess board consists of

64 squares

 This relationship goes further o It is an instance of composition, a stronger form of aggregation  Association o Models the part-whole relationship  Composition o Also models the part-whole relationship o In addition, every part may belong to only one whole o If the whole is deleted, so are the parts  Example: A number of different chess boards o Each square belongs to only one board o If a chess board is thrown away, all 64 squares on that board go as well  Composition is depicted by a solid diamond

20

A. John Blesswin [101922]

4.7.4 GENERALIZATION  Inheritance is a required feature of object orientation  Inheritance is a special case of generalization o The UML notation for generalization is an open triangle o Sometimes the open triangle is labeled with a discriminator  Every instance of Asset Class or its subclasses has an attribute assetType (the discriminator) o This attribute can be used to distinguish between instances of the subclasses

4.7.5

ASSOCIATION

 The association between the two classes may be modeled as a class o Example: Suppose the radiologist consults the lawyer on a number of occasions, each one for a different length of time  Now consults has become a class, Consults Class, which is called an association class o Because it is both an association and a class

21

A. John Blesswin [101922]

4.8 USE CASE DIAGRAMS  A use case is a model of the interaction between o External users of an information system (actors) and o The information system itself More precisely, an actor is a user playing a specific role  A use-case diagram is a set of use cases  Generalization of actors is supported o The open triangle points toward the more general case

4.9 INTERACTION DIAGRAMS  Interaction diagrams show how objects interact with one another  UML supports two types of interaction diagrams o Sequence diagrams o Collaboration diagrams 4.9.1

Sequence Diagrams

 Example: Dynamic creation followed by destruction of an object

22

A. John Blesswin [101922]

 The lifelines in the sequence diagram o An active object is denoted by a thin rectangle (activation box) in place of the dashed line  Creation of the : Masterpiece Class object is denoted by the lifeline starting at the point of dynamic creation  Destruction of that object after it receives message 9: Destroy object o is denoted by the heavy X  A message is optionally followed by a message sent back to the object that sent the original message  Even if there is a return, it is not necessary that a specific new message be sent back o Instead, a dashed line ending in an open arrow indicates a return from the original message, as opposed to a new message  There is a guard on the message 9: [offer rejected] Destroy object o Only if Osbert’s offer is rejected is message 9 sent  A guard (condition) is something that is true or false o The message sent only if the guard is true  The purpose of a guard o To ensure that the message is sent only if the relevant condition is true  Iteration an indeterminate number of times is modeled by an asterisk (Kleene star)  Example: Elevator (see next slide) *move up one floor o The message means: “move up zero or more floors”  Sequence diagram for elevator

 An object can send a message to itself o A self-call

23

A. John Blesswin [101922]

 Example: o The elevator has arrived at a floor o The elevator doors now open and a timer starts o At the end of the timer period the doors close again o The elevator controller sends a message to itself to start its timer—this self-call is shown in the previous UML diagram 4.9.2 Collaboration Diagrams  Collaboration diagrams are equivalent to sequence diagrams o All the features of sequence diagrams are equally applicable to collaboration diagrams o Use a sequence diagram when the transfer of information is the focus of attention  Use a collaboration diagram when concentrating on the classes 4.10 STATE CHARTS  The elevator is in state Elevator Moving o It performs operation Move up one floor o while guard [no message received yet] remains true, until it receives the message Elevator has arrived at floor  Receipt of this message (event) causes the guard to be false  It also enables a transition to state Stopped at Floor o In this state, activity Open the elevator doors o is performed  The most general form of a transition label is event [guard] / action o If event o has taken place and [guard] o is true, the transition occurs, and, while it is occurring, action o is performed  Statechart with guards

24

A. John Blesswin [101922]

 An event also causes transitions between states  Example: The receipt of a message

 Equivalent statement with most general transition

 The transition label is o Elevator has arrived at floor [a message has been received] / Open the elevator doors o The guard o [a message has been received] o is true when the event o Elevator has arrived at floor o has occurred and the message has been sent  The action to be taken is o Open the elevator doors  There are two places where an action can be performed in a statechart o When a state is entered Activity o As part of a transition Action  An event can be specified in terms of words like “when” or “after”  Example: o When (cost > 1000) or after (2.5 seconds) 25

A. John Blesswin [101922]

 Superstates combine related states

 States A, B, C, and D all have transitions to Next State  Combine them into superstate ABCD Combined o Now there is only one transition o The number of arrows is reduced from four to only one  States A, B, C, and D all still exist in their own right  Example: Four states are unified into MSG Combined

4.11 PACKAGE DIAGRAMS  A large information system is decomposed into relatively independent packages  UML notation for a package

26

A. John Blesswin [101922]

 Example showing the contents of My Package

4.12 DEPLOYMENT DIAGRAMS  A deployment diagram shows on which hardware component each software component is installed (or deployed)  It also shows the communication links between the hardware components  Example:

4.13 OTHER UML DIAGRAMS 4.13.1 Component Diagrams  A component diagram shows dependencies among software components, including o Source code o Compiled code 27

A. John Blesswin [101922]

o Executable load images  Example: o Programmers write source code in an object-oriented language C++ or Java o The source code is translated by a compiler into compiled code (The binary code that is the only language a computer understands) o The compiled code for each module is combined with run-time routines to produce an executable load image (that is, a program)  Example:

4.13.2 Activity Diagrams  Activity diagrams show how various events are coordinated o Used when activities are carried on in parallel  Example: o One diner orders chicken, the other fish o The waiter writes down their order, and hands it to the chef o The meal is served only when both dishes have been prepared  Example:

 A fork has o One incoming transition, and 28

A. John Blesswin [101922]

o Many outgoing transitions, each of which starts an activity to be executed in parallel with the other activities  A join has o Many incoming transitions, each of which lead from an activity executed in parallel with the other activities, and o One outgoing transition that is started when all the parallel activities have been completed  Example: A company that assembles computers as specified by the customer

 The three departments involved o Assembly Department o Order Department o Accounts Receivable Department o are each in their own swimlane

29

A. John Blesswin [101922]

Unit-5 TESTING AND MANAGEMENT ISSUES SYLLABUS: Quality issues-Non execution based testing- execution based testing- cost benefit analysis- risk analysis-Improving the process- Metrics-CPM/PERT- Choice of programming language-Reuse case studies- Portability-planning and estimating duration and cost-testing the project management plan-maintenance and the object oriented paradigm-CASE Tools for maintenance. INTRODUCTION  Traditional life-cycle models usually include a separate testing phase, after implementation and before maintenance o This cannot lead to high-quality information systems  Testing is an integral component of the information system development process o An activity that must be carried out throughout the life cycle  Continual testing carried out by the development team while it performs each workflow is essential, o In addition to more methodical testing at the end of each workflow  Verification o The process of determining whether a specific workflow has been correctly carried out o This takes place at the end of each workflow  Validation o The intensive evaluation process that takes place just before the information system is delivered to the client o Its purpose is to determine whether the information system as a whole satisfies its specifications  The words verification and validation are used as little as possible in this book o The phrase verification and validation (or V & V) implies that the process of checking a workflow can wait until the end of that workflow o On the contrary, this checking must be carried out in parallel with all information system development and maintenance activities  There are two types of testing o Execution-based testing of an artifact means running (“executing”) the artifact on a computer and checking the output  However, a written specification, for example, cannot be run on a computer o The only way to check it is to read through it as carefully as possible o This type of checking is termed nonexecution-based testing  (Unfortunately, the term verification is sometimes also used to mean nonexecution-based testing. This can also cause confusion.)  Clearly, computer code can be tested both ways o It can be executed on a computer, or o It can be carefully reviewed  Reviewing code is at least as good a method of testing code as executing it on a computer 1

A. John Blesswin [101922]

5.1 QUALITY ISSUES 5.1.1 Quality Assurance  The quality of an information system is the extent to which it satisfies its specifications  The term quality does not imply “excellence” in the information systems context o Excellence is generally an order of magnitude more than what is possible with our technology today  The task of every information technology professional is to ensure a high-quality information system at all times o However, the information system quality assurance group has additional responsibilities with regard to information system quality 5.2.2 Quality Assurance Terminology  A fault is the standard IEEE terminology for what is popularly called a “bug”  A failure is the observed incorrect behavior of the information system as a consequence of the fault  An error is the mistake made by the programmer  In other words, o A programmer makes an error that results in a fault in the information system that is observed as a failure o 5.2.3. Managerial Independence  It is important to have managerial independence between o The development team and The quality assurance group  Serious faults are often found in an information system as the delivery deadline approaches o The information system can be released on time but full of faults The client then struggles with a faulty information system or o The developers can fix the information system but deliver it late  Either way the client will lose confidence in the information system development organization  A senior manager should decide when to deliver the information system o The manager responsible for development, and o The quality assurance manager o Should report to the more senior manager  The senior manager can decide which of the two choices would be in the best interest of both the development organization and the client  A separate quality assurance group appears to add greatly to the cost of information system development o The additional cost is one manager to lead the quality assurance group  The advantage is a quality assurance group consisting of independent specialists  In a development organization with under six employees o Ensure that each artifact is checked by someone other than the person responsible for producing that artifact

2

A. John Blesswin [101922]

5.2 NON EXECUTION BASED TESTING  When we give a document we have prepared to someone else to check o He or she immediately finds a mistake that we did not see  It is therefore a bad idea if the person who draws up a document is the only one who reviews it o The review task must be assigned to someone other than the author of the document o Better still, it should be assigned to a team  This is the principle underlying the inspection o A review technique used to check artifacts of all kinds o In this form of non execution-based testing, an artifact is carefully checked by a team of information technology professionals with a broad range of skills  Advantages: The different skills of the participants increase the chances of finding a fault A team often generates a synergistic effect o When people work together as a team, the result is often more effective than if the team members work independently as individuals 5.2.1 Principles of Inspections  An inspection team should consist of from 4 to 6 individuals o Example: An analysis workflow inspection team At least one systems analyst The manager of the analysis team A representative of the next team (design team) A client representative A representative of the quality assurance group  An inspection team should be chaired by the quality assurance representative o He or she has the most to lose if the inspection is performed poorly and faults slip through  The inspection leader guides the other members of the team through the artifact to uncover any faults o The team does not correct faults o It records them for later correction  There are four reasons for this: o A correction produced by a committee is likely to be lower in quality than a correction produced by a specialist o A correction produced by an team of (say) five individuals will take at least as much time as a correction produced by one person and, therefore, costs five times as much o Not all items flagged as faults actually are incorrect It is better for possible faults to be examined carefully at a later time and then corrected only if there really is a problem o There is not enough time to both detect and correct faults No inspection should last longer than 2 hours  During an inspection, a person responsible for the artifact walks the participants through that artifact o Reviewers interrupt when they think they detect a fault 3

A. John Blesswin [101922]

o However, the majority of faults at an inspection are spontaneously detected by the presenter  The primary task of the inspection leader is o To encourage questions about the artifact being inspected and promote discussion  It is absolutely essential that the inspection not be used as a means of evaluating the participants  If that happens o The inspection degenerates into a point-scoring session o Faults are not detected  The sole aim of an inspection is to highlight faults o Performance evaluations of participants should not be based on the quality of the artifact being inspected o If this happens, the participant will try to prevent any faults coming to light  The manager who is responsible for the artifact being reviewed should be a member of the inspection team o This manager should not be responsible for evaluating members of the inspection team (and particularly the presenter) o If this happens, the fault detection capabilities of the team will be fatally weakened. 5.2.2 How Inspections are performed  An inspection consists of five steps:  An overview of the artifact to be inspected is given o Then the artifact is distributed to the team members  In the second step, preparation, the participants try to understand the artifact in detail o Lists of fault types found in recent inspections ranked by frequency help team members concentrate on areas where the most faults have occurred  In the inspection, one participant walks through the artifact with the inspection team o Fault finding now commences o The purpose is to find and document faults, not to correct them o Within one day the leader of the inspection team (the moderator) produces a written report of the inspection.  The fourth stage is the rework o The individual responsible for that artifact resolves all faults and problems noted in the written report  In the follow-up, the moderator ensures that every single issue raised has been resolved satisfactorily o By either fixing the artifact or o Clarifying items incorrectly flagged as faults o If more than 5 percent of the material inspected has been reworked, the team must reconvene for a 100 percent re-inspection  Input to the inspection: o The checklist of potential faults for artifacts of that type  Output from the inspection o The record of fault statistics Recorded by severity (major or minor), and Fault type  The fault statistics can be used in a number of different ways 4

A. John Blesswin [101922]

5.2.3 Use of Fault Statistics  The number of faults observed can be compared with averages of faults detected in those same artifact types in comparable information systems o This gives management an early warning that something is wrong, and o Allows timely corrective action to be taken  If a disproportionate number of faults of one type are observed, management can take corrective action  If the detailed design of a module reveals far more faults than in any other module o That module should be redesigned from scratch  Information regarding the number and types of faults detected at a detailed design inspection will aid the team performing the code inspection of that module at a later stage 5.3 EXECUTION BASED TESTING  The first Unified Process workflow is the Requirements workflow. The artifacts of this workflow are diagrams and documents. Accordingly the requirement artifact have to undergo non execution based testing.  Next comes the Analysis workflow. Again the artifacts of this workflow are diagrams and documents and again non execution based testing is the only alternative.  Next workflow is Design workflow o The artifacts of these workflow are diagrams and documents o Testing has to be non execution-based  Why then do systems analysts need to know about execution-based testing? 5.3.1 The Relevance of Execution-Based Testing  Not all information systems are developed from scratch  The client’s needs may be met at lower cost by a COTS package  In order to provide the client with adequate information about a COTS package, - The systems analyst has to know about execution-based testing 5.3.2 Principles of Execution-Based Testing  Claim: o Testing is a demonstration that faults are not present  Fact: o Execution-based testing can be used to show the presence of faults o It can never be used to show the absence of faults  Run an information system with a specific set of test data o If the output is wrong then the information system definitely contains a fault, but o If the output is correct, then there still may be a fault in the information system All that is known from that test is that the information system runs correctly on that specific set of test data  If test data are chosen cleverly o Faults will be highlighted  If test data are chosen poorly o Nothing will be learned about the information system

5

A. John Blesswin [101922]

5.3.3 The Two Basic Types of Test Cases  Black-box test cases: o Drawn up by looking at only the specifications The code is treated as a “black box” (in the engineering sense) “We do not look inside the box”  Glass-box test cases - Drawn up by carefully examining the code and finding a set of test cases that, when executed, will together ensure that every line of code is executed at least once » These are called glass-box test cases because now we look inside the “box” and examine the code itself to draw up the test cases 5.3.4 What Execution-Based Testing Should Test  Correctness is by no means enough  Five other qualities need to be tested: o Utility o Reliability o Robustness o Performance o Correctness  Utility is the measure of the extent to which an information system meets the user’s needs o Is it easy to use? o Does it perform useful functions? o Is it cost effective?  Reliability is a measure of the frequency and criticality of information system failure o How often does the information system fail?  (Mean time between failures) o How bad are the effects of that failure? o How long does it take to repair the system? (Mean time to repair) o How long does it take to repair the results of the failure?  Robustness is a measure of a number of factors including o The range of operating conditions o The possibility of unacceptable results with valid input, and o The acceptability of effects when the information system is given invalid input  Performance constraints must be met o Are average response times met? (Hard real-time constraints rarely apply to information systems Correctness- An information system is correct if it satisfies its specifications  Every information system has to be correct  But in addition, it must pass execution-based testing of o Utility o Reliability o Robustness, and o Performance

6

A. John Blesswin [101922]

5.4 COST BENEFIT ANALYSIS  An information system will be constructed only if it is cost-effective to do so  A popular technique for determining this o Compare estimated future benefits against projected future costs o This is termed cost-benefit analysis  Tangible benefits are easy to measure, but o Intangible benefits can be hard to quantify directly  A way of assigning a dollar value to intangible benefits is to make assumptions o In the absence of data, this is the best that can be done o Better assumptions mean better data and more accurate calculation of intangible benefits  The same technique can be used for intangible costs  Cost-benefit analysis is a fundamental technique for deciding o Whether a client should computerize his or her business and, if so o In what way  For each strategy, costs and benefits are computed o Select the strategy for which the difference between benefits and costs is the largest 5.5 RISK ANALYSIS  A risk is an event or condition that can cause the delivery of an information system to be o Canceled o Delayed o Over budget, or o Not to meet its requirements  Risks include: o The project may not meet its time constraints o The moving target problem can result in time and cost overruns o The delivered information system may not meet the client’s real needs o The developers may not have the needed expertise o The hardware may not be delivered in time o The CASE tools may not be available, or may not have all the needed functionality o A COTS package with the same functionality may be put on the market while the project is underway  The first step o List the risks in a project  Risk management is the process of o Determining what the risks are, and then o Attempting to mitigate them Minimize their impact  Example 1: o To mitigate the risk that part of a proposed information system will not work Build a proof-of-concept prototype  Example 2: o To mitigate the risk that the development team will not have the necessary skills Provide training 7

A. John Blesswin [101922]

 Risks are like diseases o Sometimes they go away spontaneously o They often get better or worse without intervention o Minor ones merely need to be watched, but o Major ones need to be cured (mitigated)  A risk list must therefore be maintained  For each item on the list, the following items are recorded: o A description of the risk o The priority of the risk (critical, significant, or routine) The priority can change, in either direction o The way the project is impacted by the risk o The name of the person responsible for monitoring the risk o The action to be taken if the risk materializes  Risk analysis is integral to the Unified Process  During the inception phase o The risk list is drawn up o Attempts are made to mitigate the critical risks o The use cases are prioritized according to their risks  During the elaboration phase o The risks are monitored o The risk list is updated Particularly with regard to priorities  During the construction phase o The risk list is again updated  During the transition phase o Attempts are made to find any previously unidentified risks  Risk analysis does not terminate when the product is delivered to the client o The risk list must be maintained through the entire life cycle of the product 5.6 IMPROVING THE PROCESS  The global economy is critically dependent on computers o And hence on information systems  Many governments are concerned about the information system development process o This includes the activities, techniques, and tools used to produce information systems  The Department of Defense founded the Software Engineering Institute at Carnegie Mellon University in Pittsburgh  A major success of the Software Engineering Institute is the Capability Maturity Model (CMM) 5.6.1 Capability Maturity Models  The capability maturity models of the Software Engineering Institute o A related group of strategies for improving the process for developing information systems  (Maturity is a measure of the goodness of the process itself)  The Software Engineering Institute has developed CMMs for 8

A. John Blesswin [101922]

o Software (SW-CMM) o Management of human resources (P-CMM; the P is for “people”) o For systems engineering (SE-CMM) o For integrated product development (IPD-CMM), and o For software acquisition (SA-CMM)  In 1997 it was decided to develop a single integrated framework for maturity models o Capability maturity model integration (CMMI)  SW-CMM is presented here o SW-CMM incorporates technical and managerial aspects of the development of an information system  Underlying principle: o The use of new techniques cannot result in increased productivity and profitability o Problems are caused by the way the process is managed o Improving the management of the process will result in Improvements in technique Better-quality information systems, and Fewer projects with time and cost overruns  Improvements in the process cannot occur overnight o The SW-CMM induces change incrementally  Five different levels of maturity are defined o An organization advances slowly toward the higher levels of process maturity Maturity Level 1: Initial Level  No information system management practices are in place o Instead, everything is done ad hoc o Most activities are responses to crises o The process is unpredictable o It is impossible to make accurate time and cost estimates  Most development organizations worldwide are still at level 1 Maturity Level 2: Repeatable Level  Basic information system project management practices are in place o Planning and management techniques are based on experience Hence the name “repeatable” o Measurements are taken The essential first step in achieving an adequate process o Without measurements, it is impossible to detect problems before they get out of hand o Also, measurements taken during one project can be used to draw up realistic schedules for future projects Maturity Level 3: Defined Level  The process for information system development is fully documented o Managerial and technical aspects of the process are clearly defined 9

A. John Blesswin [101922]

Continual efforts are made to improve the process  At this level, it makes sense to introduce new technology such as CASE o In contrast, “high tech” only makes the crisis-driven level 1 process even more chaotic  A number of organizations have attained maturity levels 2 and 3 o Not many have reached levels 4 or 5  For most companies the two highest levels are targets for the future Maturity Level 4: Managed Level  A level 4 organization sets quality and productivity goals for each project o These two quantities are measured continually o Action is taken if there are deviations from the goals Maturity Level 5: Optimizing Level  The goal of a level 5 organization is continuous process improvement o Statistical quality and process control techniques are used to guide the organization  The knowledge gained from each project is utilized in future projects o The process thus incorporates a positive feedback loop  The five maturity levels

Figure : Maturity Levels To improve its process, an organization o Attempts to understand its current process o Formulates the intended process o Determines and ranks in priority actions that will achieve this process improvement o Draws up and executes a plan to accomplish this improvement  This series of steps then is repeated o The organization successively improves its process  Experience with the capability maturity model o Advancing a complete maturity level usually takes from 18 months to 3 years But moving from level 1 to level 2 can take up to 5 years It is difficult to instill a methodical approach in a level 1 organization  For each maturity level there are key process areas that an organization should target to reach the next maturity level  Example: The key process areas for level 2 include o Configuration control 10

A. John Blesswin [101922]

o Quality assurance o Project planning o Project tracking o Requirements management  These areas cover the basic elements of information system management: o Determine the client’s needs (requirements management) o Draw up a plan (project planning) o Monitor deviations from that plan (project tracking) o Control the pieces that make up the information system (configuration management), and o Ensure that the information system is fault free (quality assurance)  A level 5 organization is far more advanced than a level 2 organization  Example: o A level 2 organization is concerned with quality assurance, that is, with detecting and correcting faults o The process of a level 5 organization incorporates fault prevention, that is, ensuring there are no faults in the first place  An original goal of the CMM program was to raise the quality of defense software o By awarding contracts to only those defense contractors who demonstrate a mature process  The U.S. Air Force stipulated conformance to SW-CMM level 3 by 1998 o The Department of Defense as a whole subsequently issued a similar directive  Today, the SW-CMM program is being implemented by development organizations worldwide 5.7 METRICS  Measurements (or metrics) are essential to detect problems early in the information system process O before they get out of hand  Metrics serve as an early warning system for potential problems  A wide variety of metrics can be used, such as O loc measurements O mean time between failures O effort in person-months O personnel turnover O cost O efficiency of fault detection  Gathering metrics data costs money O even when data gathering is automated, the case tool that accumulates the information is not free O interpreting the output from the tool consumes human resources  Numerous different metrics have been put forward O which metrics should an information system organization measure?  There are five essential, fundamental metrics: O size (in lines of code, or better) O cost (in dollars) O duration (in months) 11

A. John Blesswin [101922]

O effort (in person-months), and O quality (number of faults detected)  Each metric must be measured by phase or workflow  Data from these fundamental metrics can highlight problems such as O high fault rates during the design workflow O code output that is well below the industry average  A strategy to correct these problems is then put into place  To monitor the success of this strategy, more detailed metrics can be introduced 5.8 CPM/PERT  More general types of management information are also needed  example: O critical path management (cpm), otherwise known as O program evaluation review techniques (pert)  When developing an information system O many hundreds of activities have to be performed O some activities have to precede others O other activities can be carried on in parallel  example: O two activities are started at the same time O they can be performed in parallel O both have to be completed before proceeding with the project as a whole O the first takes 12 days, but the second needs only 3 days  The first activity is critical O any delay in the first activity will cause the project as a whole to be delayed  However, the second activity can be delayed up to 9 days without adversely impacting the project O there is a slack of 9 days associated with the second activity  When using pert/cpm, the manager inputs O the activities O their estimated durations O any precedence relations  The pert/cpm package will then O determine which of the hundreds of activities are critical O compute the slack for each of the noncritical activities O print out a pert chart showing the precedence relationships, and O highlight the critical path the path through the chart that consists of critical activities only if any activity on the critical path is delayed, then so is the project as a whole  Simple PERT chart

12

A. John Blesswin [101922]

 There are 12 activities and 9 milestones O a milestone is an event used to measure progress, such as the completion of an activity or set of activities  Starting with milestone a, activities ab, ac, and ad can be started in parallel  Activity fj cannot start until both bf and cf are finished  The project as a whole is complete when activities hj, fj, and gj are all complete  Completing the whole project will take at least 25 days  The critical path is acgj O if any one of the critical activities ac, cg, or gj s delayed in any way, the project as a whole will be delayed  However, if activity ad is delayed by up to 15 days, the project as a whole will not be delayed O there is a slack of 15 days associated with activity ad  Now suppose that activity ad is delayed by 15 days  The situation at day 17 O actual durations of completed activities are underlined

 There are now two critical paths o Activity DG has become critical  Simply printing out a PERT chart showing the expected durations is useless o Data regarding actual durations must be input continually o The PERT chart must be updated  How is the PERT data continually updated? o The task is too large for humans—a CASE tool is needed o All the information system development tools must integrated o Information of all kinds, including Source code Designs Documentation Contracts, and Management information  must be stored in a system development database  The CASE tool that generates the PERT chart then obtains its information directly from the database o Thus, what is needed is a CASE environment 13

A. John Blesswin [101922]

5.9 CHOICE OF PROGRAMMING LANGUAGE  In what language should the information system be implemented? o This is usually specified in the contract  But what if the contract specifies o The product is to be implemented in the “most suitable” programming language  What language should be chosen?  Example o QQQ Corporation has been writing COBOL programs for over 25 years o Over 200 software staff members, all with COBOL expertise o What is “the most suitable” programming language?  Obviously COBOL  What happens when new language (Java, say) is introduced o New hires are needed o Existing professionals must be retrained o Future products are written in Java o However, existing COBOL products must be maintained o Expensive software is needed, and the hardware to run it o 100s of person-years of expertise with COBOL are wasted  There are now two classes of programmers o COBOL maintainers (despised) o Java developers (paid more)  The solution: OO-COBOL Object-oriented COBOL—2002  QQQ Corporation train their technical staff in o The object-oriented paradigm in general, and o OO-COBOL in particular  QQQ Corporation can then o Develop new information systems in OO-COBOL, and o Maintain existing information systems in traditional COBOL  Where there is no clear reason for choosing one programming language over another o Use cost-benefit analysis Management must compute costs and benefits of each language under consideration The language with the largest expected gain is chosen o Alternatively, risk analysis can be used For each language, a list is made of the potential risks and ways of mitigating them The language with the smallest overall risk is selected  Which is the appropriate object-oriented language today? o Twenty years ago, there was only one choice—Smalltalk o Today the most widely used object-oriented language is C++ o Java is in second place C++ is popular because of its similarity to C o C++ is a superset of C o C++ is therefore a hybrid object-oriented language

14

A. John Blesswin [101922]

o Managers therefore often assume that a C programmer can quickly pick up the rest o Conceptually C++ is quite different from C o C is for the traditional paradigm o C++ is for the object-oriented paradigm o Before an organization adopts C+ o Training in the object-oriented paradigm must be given Java is a pure object-oriented programming language  Education and training are even more important with Java than a hybrid object-oriented language o Like C++ or OO-COBOL  What of the future?  Existing information systems o COBOL will remain the most widely used language  New information systems o Will be written in object-oriented languages like C++ Java C# 5.10 REUSE CASE STUDIES  Instead of utilizing previously developed programs, organizations all over the world develop their own programs from scratch o Why do information technology professionals continually reinvent the wheel? 5.10.1 Reuse Concepts  Reuse o Using artifacts of one information system when developing a different information system with different functionality  Reusable artifacts include o Modules o Code fragments o Design artifacts o Part of manuals o Sets of test data o Duration and cost estimates  Two types of reuse o Accidental reuse (or opportunistic reuse) First, the information system is built Then, artifacts are put into the artifact database for reuse o Planned reuse First, reusable artifacts are constructed Then, information systems are built using these artifacts  A strength of deliberate reuse o A artifacts specially constructed for reuse are likely to be Easy and safe to reuse Robust 15

A. John Blesswin [101922]

Well documented Thoroughly tested Uniform in style  A weakness of deliberate reuse o There can be no guarantee that such an artifact will ever be reused  Reasons for reuse o It is expensive to design, implement, test, and document software o On average, only 15% of new code serves an original purpose o Reuse of parts saves Design costs Implementation costs Testing costs Documentation costs  So why do so few organizations employ reuse? 5.10.2 Impediments to Reuse  There are a number of obstacles to reuse: o The not invented here (NIH) syndrome o Concerns about faults in potentially reusable routines o The storage-retrieval problem o Costs of reuse  All these can be solved  Legal issues can arise with a contract information system o The information system usually belongs to the client o Reuse of an artifact for another client constitutes theft of intellectual property 5.11 PORTABILITY  Every information system must be portable o That is, easily adapted to run on different hardware-operating combinations  Hardware is replaced every 4 years or so  There are several obstacles to portability

system

5.11.1 Hardware Incompatibilities  Sources of incompatibilities include o Diskette formats (PC vs. Macintosh) o Character codes (EBCDIC vs. ASCII) o Tape drives (different parities)  There is an economic reason for perpetuating incompatibilities o To force a customer to buy an expensive compatible computer To avoid an even more expensive conversion to a cheaper incompatible computer 5.11.2 Operating System Incompatibilities  An information system that runs under Windows will not run under 16

A. John Blesswin [101922]

o Linux o Mac OS, or o OS/370  Problems can arise even when upgrading the same operating system o Example: Windows 5.11.3 Compiler Incompatibilities  Information systems should be implemented in a widely used language such as o COBOL o C o C++, or o Java  Using only standard features of that language 5.12

PLANNING AND ESTIMATING DURATION AND COST

5.12.1 Planning  There are two types of planning o Planning, like testing, must continue throughout the development and maintenance life cycle o After the specification document has been drawn up, duration and cost estimates are computed and a detailed plan is produced Planning and the Information System Life Cycle  Ideally, the plan for the entire information system project would be drawn up at the very beginning of the life cycle  This is impossible o There is insufficient information that early  There is not enough information available at the end of the requirements workflow to plan the system o At that stage, the developers at best have an informal understanding of what the client needs  Planning has to wait until the end of the analysis workflow o At that stage, the developers have a detailed appreciation of most aspects of the target information system o This is the earliest point in the life cycle at which accurate duration and cost estimates can be determined  Suppose that the delivered cost of an information system is found to be $1 million  The figure shows that if a cost estimate had been made - Midway through the requirements workflow, the relative range for the cost estimate was 4 o The cost estimate was probably in the range ($1 million / 4, $1 million 4), or ($0.25 million, $4 million) – Midway through the analysis workflow the relative range for the cost estimate was 2 17

A. John Blesswin [101922]

–

o The range of likely estimates would have shrunk to ($1 million / 2, $1 million 2), or ($0.5 million, $2 million) At the end of the analysis workflow, the relative range at this point was 1.5 o The estimate was probably in the still relatively wide range of ($1 million / 1.5, $1 million 1.5) or ($0.67 million, $1.5 million)

Figure : Early estimates can be wildly inaccurate l  Cost estimation is not an exact science - And a premature estimate is likely to be even less accurate than one made at the correct time  The assumption throughout the remainder of this chapter is that - The analysis workflow has been completed, so meaningful estimating and planning now can be carried out 5.12.2 Estimating Duration and Cost  Before development commences, the client wants to know how much the information system will cost - If the development team underestimates, the development organization will lose money on the project - If the development team overestimates, then the client may decide against proceeding, or - The client may give the job to another development organization whose estimate is more reasonable  Accurate cost estimation is critical  Internal cost - The cost to the developers, including o Salaries of the development teams, managers, and support personnel o The cost of the hardware and software o The cost of overhead such as rent, utilities, and salaries of senior management  External cost - The cost to the client 18

A. John Blesswin [101922]

 Sometimes - External cost = internal cost + profit margin  However, economic and psychological factors can affect this - If the developers desperately need work they may charge the client the internal cost or less - When a contract is awarded on the basis of bids, a team may try to come up with a bid that will be slightly lower than what they believe will be their competitors’ bids  Estimating the duration of the project is equally important - The client wants to know when the finished information system will be delivered  If the project falls behind schedule - At best the developers lose credibility – At worst penalty clauses are invoked  If the developments overestimate the time needed - The client will probably go elsewhere  It is hard to estimate duration and cost accurately - The human factor is critical  Experiments of Sackman - With matched pairs, Sackman observed differences of o 6 to 1 in information system size o 8 to 1 in information system execution time o 9 to 1 in development time o 18 to 1 in coding time o 28 to 1 in debugging time – The best and worst performances were by two programmers, each of whom had 11 years of experience  Human factors therefore preclude accurate estimates of duration or cost  Differences among individuals do not tend to cancel out, even on large projects - One or two very good (or very bad) team members can cause major deviations from estimations  Critical staff members can resign during the project - Time and money then are spent o Finding replacements and integrating them into the team, or o Reorganizing the remaining team members – Schedules slip and estimates become inaccurate 5.12.3 Metrics for the Size of an Information System  The most common size metric - Lines of code (LOC), or – Thousand delivered source instructions

(KDSI)

 There are many problems with this metric - Source code is only a small part of the development effort – Versions in different languages have different numbers of lines of code – Should comments in the code be counted? – How should changed lines or deleted lines be counted? – What if code is not written, but rather inherited from a parent class? 19

A. John Blesswin [101922]

-

Not all the code written is delivered to the client o Half the code may be for tools – What if thousands of lines are generated by o A report generator o A screen generator, or o A graphical user interface (GUI) generator  Some metrics estimate size on the basis of the estimated number of lines of code  This is doubly dangerous  It is an uncertain input to an uncertain formula Alternatives to lines of code - So-called software science o Anything but science!  What is required is a metric that can be computed from quantities available early in the life cycle - FFP metric o Size = Number of Files + Number of Flows + Number of Processes o Validated for medium-scale information systems o Never extended to databases – Function points – Function points o Based on the number of input items, output items, inquiries, master files, and interfaces o The metric also incorporates the effects of 14 technical factors

 Function points and the FFP metric have the same disadvantage - Maintenance often is inaccurately measured – Major changes can be made without changing » The number of files, flows, and processes or » The number of inputs, outputs, inquiries, master files, and interfaces » (Lines of code is no better in this respect)

20

A. John Blesswin [101922]

5.12.4 Techniques of Cost Estimation  Expert judgment by analogy - An expert compares the target information system to completed systems and notes similarities and differences - Different estimates from experts are reconciled using the Delphi technique – Estimates and rationales are distributed to all the experts – They now produce a second estimate – Estimation and distribution continue until the experts agree within an accepted tolerance - No group meetings take place during the iteration process – Estimation by a group of experts should reflect their collective experience » If this is broad enough, the result well may be accurate  Algorithmic cost estimation models - A metric is used as input to a model – The model is then used to estimate duration and cost  Unlike a human, a model is unbiased - However, estimates from a model are only as good as its underlying assumptions  Hybrid models incorporate mathematical equations, statistical modeling, and expert judgment - The most important hybrid model is COCOMO 5.12.4.1 COCOMO  COCOMO estimation is done in two stages  First, a rough estimate of the development effort is determined, based on - The number of lines of code in the target system, and – The level of difficulty of developing that target system  From these two parameters, the nominal effort can be computed  Example: - The target information system is straightforward, and – Estimated to be 12,000 lines of code  The nominal effort will be 43 person-months  Second, the nominal effort is multiplied by 15 development effort multipliers, such as - Required software reliability, and – Product complexity to yield the estimated effort – The multipliers can range in value from 0.70 to 1.66  Example: - A network of ATMs is complex and the network has to be reliable – According to the COCOMO guidelines, the multiplier - Required software reliability is 1.15, and – Product complexity is 1.30  The estimated effort is then used in additional formulas to determine various estimates, including - Dollar costs – Development schedules – Activity distributions 21

A. John Blesswin [101922]

- Annual maintenance costs  COCOMO is a complete algorithmic cost estimation model - It gives the user virtually every conceivable assistance in project planning  COCOMO has proved to be the most reliable estimation method - Actual values come within 20 percent of the predicted values about two thirds of the time  The major problem with COCOMO - Its most important input is the number of lines of code in the target information system - If this estimate is incorrect, then every single prediction of the model may be incorrect  Management must monitor all predictions throughout information system development 5.12.4.2 COCOMO II  COCOMO II is both flexible and sophisticated - Consequently, it is much more complex than the original COCOMO  The model still is too new to estimate - Its accuracy, and – The extent to which it is an improvement over the original COCOMO 5.12.4.3 Tracking Duration and Cost Estimates  While the information system is being developed - Actual development effort must constantly be compared against predictions  Deviations from predictions serve as early warnings that - Something has gone wrong, and – Corrective action must be taken  Management must then take appropriate action to minimize the effects of - Cost overruns, and – Duration overruns  Careful tracking of predictions must be done throughout the development process - Irrespective of the prediction techniques that were used  Detect deviations early in order to - Take immediate corrective action 5.13

TESTING THE PROJECT MANAGEMENT PLAN

 Cost and duration estimates must be as accurate as possible  The entire project management plan must be checked by the quality assurance group before estimates are given to the client o The best way to test the plan is by a plan inspection  The plan inspection team must review the project management plan in detail o Special attention must be paid to the duration and cost estimates  To reduce risks even further o As soon as the members of the planning team have determined their estimates, duration and cost estimates should be computed independently by a member of the quality assurance group 22

A. John Blesswin [101922]

 This must be done irrespective of the metrics used 5.14

MAINTENANCE AND THE OBJECT ORIENTED PARADIGM

5.14.1 MAINTENANCE—DEFINITION  Maintenance is the process that occurs when an information system artifact is modified o Either because of a problem, or o Because of a need for improvement or adaptation (International Standards Organization and International Electro technical Commission, 1995)  That is, maintenance occurs whenever an information system is modified o Regardless of whether this takes place before or after installation 5.14.2 WHY MAINTENANCE IS NECESSARY  There are three main types of maintenance:  Corrective maintenance o To correct a fault  Perfective maintenance o To improve the effectiveness of the information system  Adaptive maintenance o To react to changes in the environment in which the information system operates 5.14.3 DEVELOPMENT AND MAINTENANCE  The information system life cycle can be viewed as an evolutionary process o This is how maintenance is viewed by the Unified Process o Maintenance is treated merely as another increment  However, there is a basic difference between development and maintenance o It is easier to create a new version than to modify an existing version  Example  Consider the similarities and differences between o Modifications to a portrait o Modifications to a information system o Conclusions o A new portrait must be painted from scratch o The existing information system must be modified 5.14.4 MAINTENANCE AND THE OBJECT-ORIENTED PARADIGM  The object-oriented paradigm promotes maintenance o A class is an independent unit o Example: Bank Card Class models every aspect of a bank card No aspects of a bank card are modeled by any other class o Information hiding ensures that implementation details are not visible outside a class o Message passing is the only form of communication permitted 23

A. John Blesswin [101922]

 In theory, it is easy to maintain a class o Independence ensures it will be easy to determine which part of an information system must be changed o Information hiding ensures that a change made to a class will have no impact outside that class o This reduces regression faults  In practice, there are obstacles specific to the maintenance of object-oriented information systems  Inheritance is the cause of some problems  If new features is added to a class with no subclasses, there is no effect on any other class, but  If a class with subclasses is changed, all its subclasses are changed in the same way  Inheritance hierarchy

Figure :Inheritance hierarchy  A new attribute added to class Bottom Class cannot affect any other class in any way  A new attribute added to class Top Class applies to all the classes in the diagram o This is termed the fragile class problem  Inheritance can have o A positive influence on development, but o A negative impact on maintenance  A second problem arises as a consequence of polymorphism and dynamic binding  Create new subclass via inheritance o Does not affect super class o Does not affect any other subclass  Modify this new subclass o Again, no affect  Modify a super class o All descendent subclasses are affected  Inheritance can have o A positive effect on development o A negative effect on maintenance

24

A. John Blesswin [101922]

 Key point o Maintainers must not merely be skilled in a broad variety of areas, they must be highly skilled in all those areas o Specialization is impossible for the maintainer  Maintenance is the same as development, only more so 5.14.5 Reverse Engineering  When the only documentation is the code itself o Start with the code o Recreate the design artifacts o Recreate the specification artifacts (extremely hard) o CASE tools can help (flow charters, other visual aids)  This is a common problem with legacy systems  Definitions o Reengineering Reverse engineering, followed by forward engineering o Restructuring Improving the information system without changing its functionality o Examples: Pretty printing Converting code from traditional to object-oriented form Improving maintainability Testing during Maintenance  Maintainers view an information system as a set of loosely related code artifacts o They were not involved in the development of the product  Regression testing is essential o Store test cases and their outcomes, modify as needed 5.15 CASE TOOLS FOR MAINTENANCE.  Version control tools are essential  Configuration control tools are essential - Examples: » Commercial: PVCS, SourceSafe » Open source: CVS  If no configuration control tool is available - A build tool is required  A fault tracking tool is also needed - It keeps a record of reported faults that are not yet fixed – Example: » Open source: Bugzilla  CASE tools can assist in reverse engineering and reengineering - Examples » Commercial: Battlemap, Teamwork  Maintenance is difficult and frustrating - Management must provide maintenance programmers with the CASE tools needed for efficient and effective maintenance. 25

A. John Blesswin [101922]