KARNATAKA STATE OPEN UNIVERSITY Sub: OBJECT ORIENTED S/W ENGINEERING WITH UML MTech(IT)

Subject Code : MT-21 ASSIGNMENT-1

Q.1

What is software reusability?

In computer science and software engineering, reusability is the likelihood a segment of structured code can be used again to add new functionalities with slight or no modification. Reusable code reduces implementation time, increases the likelihood that prior testing and use has eliminated bugs and localizes code modifications when a change in implementation is required. Subroutines or functions are the simplest form of reuse. A chunk of code is regularly organized using module or namespace. Proponents claim that Objects and software components offer a more advanced form of reusability. Software reusability more specifically refers to design features of a software element (or collection of software elements) that enhance its suitability for reuse. Candidate design features for software reuse include:

Adaptable Brief: small size Flexible Parameterization Generic Fast Simple: low complexity Localization of volatile (changeable) design assumptions (David Parnas)

Consensus has not yet been reached on this list or the relative importance of the entries nor on the issues, which make each one important for a particular class of applications. Q.2 Describe s/w process and project management?

A series of predictable steps of activities used to create a timely, high-quality result is called a software process. Software engineers and their managers adapt the process to their needs and then follow it. In addition, the people who have requested the software play a role in the software process. A software process can be characterized as shown in Figure, A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. A number of task sets - each a collection of software engineering work tasks, project milestone. The term legacy programs is a euphemism for older, often poorly designed and documented software that is business critical and must be supported over many years.

The approach to development can be an iterative one. It involves repeated refinement of the object model. The process needs to be controlled by an appropriate project management process, involving reviews and check pointing at the levels of: Analysis Design Implementation Post Implementation Review

Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications The project schedule and project plan must be tracked and monitored on a continuing basis. In addition, a manager should use tools to collect metrics that will ultimately provide an indication of software product quality. Tools in the category are often extensions to project planning tools A repository contains information not only about the software application itself, but also about the characteristics of each particular project and the organization's general process for software development (phases, tasks, and deliverables). This opens up possibilities for automated coordination of technical development activity with the project management activity. For example, updating the status of project tasks could be done automatically or as a by-product of using the CASE tools. Status updating can be made very easy for developers to perform without having to leave the normal development environment. Task assignment and queries can also be handled by e-mail. Problem reports, maintenance tasks, change authorization, and repair status can be coordinated and monitored via tools accessing the repository Software Process Improvement is crucial as any organization attempts to take on and deliver larger projects. The lack of well-defined software processes can be
2

very costly. Support from all staff, especially top management, is a prerequisite for any serious SPI initiative. As a great philosopher once said, "It won't happen overnight, but it will happen". Many improvement efforts fail or falter during the initial phases of process improvement. -Wesley, 1989. Q.3 What do you understand by Requirement Elicitation?

In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering. The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Christel and Kang [CRI92] identify a number of problems that help us understand why requirements elicitation is difficult: Problems of scope. The boundary of the system is ill-defined or the customers/ users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, dont have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be obvious, specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable. Problems of volatility. The requirements change over time. To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner. What is role of use case diagrams in UML?

Q.4

A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task. Use cases are used in almost every project. The are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases. Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. 2. 3. 4. 5. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

This example shows the customer as a actor because the customer is using the ordering system. The diagram takes the simple steps listed above and shows them as actions the customer might perform. The salesperson could also be
4

included in this use case diagram because the salesperson is also interacting with the ordering system. From this simple diagram the requirements of the ordering system can easily be derived. The system will need to be able to perform actions for all of the use cases listed. As the project progresses other use cases might appear. The customer might have a need to add an item to an order that has already been placed. This diagram can easily be expanded until a complete description of the ordering system is derived capturing all of the requirements that the system will need to perform. Q.5 What is sequence diagram?

UML sequence diagrams are used to represent or model the flow of messages, events and actions between the objects or components of a system. Time is represented in the vertical direction showing the sequence of interactions of the header elements, which are displayed horizontally at the top of the diagram. Sequence Diagrams are used primarily to design, document and validate the architecture, interfaces and logic of the system by describing the sequence of actions that need to be performed to complete a task or scenario. UML sequence diagrams are useful design tools because they provide a dynamic view of the system behavior which can be difficult to extract from static diagrams or specifications. Although UML sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence charts and call flows for telecom/wireless system design, and for protocol stack design and analysis Sequence Diagram Header Elements The header portion of the sequence diagram represents the components or objects of the system being modeled and are laid out horizontally at the top of the diagram. See an example sequence diagram here. Actor Object Unit Represents an external person or entity that interacts with the system Represents an object in the system or one of its components Represents a subsystem, component, unit, or other logical entity in the system (may or may not be implemented by objects) Represents an interface or boundary between subsystems, components or units (e.g., air interface, Internet, network) Groups related header elements into subsystems or components

Separator

Group

Sequence Diagram Body Elements Action Represents an action taken by an actor, object or unit Asynchronous An asynchronous message between Message header elements Block A block representing a loop or conditional for a particular header element Call Message Create Message Destroy Element Destroy Message Diagram Link A call (procedure) message between header elements A "create" message that creates a header element (represented by lifeline going from dashed to solid pattern) Represents the destruction of a header element Represents the destruction of a header element as a result of a call from another element Represents a portion of a diagram being treated as a functional block. Similar to a procedure or function call that abstracts functionality or details not shown at this level. Can optionally be linked to another diagram for elaboration. Represents an "else" block portion of a diagram block Documentation note that is automatically formatted to flow after previous elements Documentation note that is free-flowing and can be placed anywhere in the diagram (can also be anchored relative to a flow element) A simple message between header elements A page break in the diagram

Else Block

Flow Note Free Note

Message Page Break

Return A return message between header Message elements Scenario Start Start of a scenario (set of alternatives) Scenario Case Start of an alternative or case in a scenario Scenario End End of a scenario State Steady State A state change for a header element A steady state in the system

Timer Start Timer Stop Timer Expiration Q.6

Start of a timer for a particular header element Stop of a timer for a particular header element Expiration of a timer for a particular header element

What do you understand by terms software reliability?

The probability that software will contribute to failure-free system performance for a specified time under specified conditions. Software reliability is a special aspect of reliability engineering. System reliability, by definition, includes all parts of the system, including hardware, software, operators and procedures. Traditionally, reliability engineering focuses on critical hardware parts of the system. Since the widespread use of digital integrated circuit technology, software has become an increasingly critical part of most electronics and, hence, nearly all present day systems. There are significant differences, however, in how software and hardware behave. Most hardware unreliability is the result of a component or material failure that results in the system not performing its intended function. Repairing or replacing the hardware component restores the system to its original unfailed state. However, software does not fail in the same sense that hardware fails. Instead, software unreliability is the result of unanticipated results of software operations. Even relatively small software programs can have astronomically large combinations of inputs and states that are infeasible to exhaustively test. Restoring software to its original state only works until the same combination of inputs and states results in the same unintended result. Software reliability engineering must take this into account. Despite this difference in the source of failure between software and hardware software doesnt wear out some in the software reliability engineering community believe statistical models used in hardware reliability are nevertheless useful as a measure of software reliability, describing what we experience with software: the longer you run software, the higher the probability youll eventually use it in an untested manner and find a latent defect that results in a failure. As with hardware, software reliability depends on good requirements, design and implementation. Software reliability engineering relies heavily on a disciplined software engineering process to anticipate and design against unintended consequences. There is more overlap between software quality engineering and software reliability engineering than between hardware quality and reliability. A good software development plan is a key aspect of the software reliability program. The software development plan describes the design and coding standards, peer reviews, unit tests, configuration management, software metrics and software models to be used during software development. Q.7 What is component based s/w engineering?

"Component-Based Software Engineering (CBSE) is now the way to produce software fast, with less effort, of high quality -- not just the first time a product is released but for its entire life. More and more it is being applied to industrial strength and mission-critical software. It is becoming the indispensable element in the mainstream of the software world. Building large-scale and complex software systems from available parts is an
7

emerging strategy in industry. Its goals, among others, are to consistently increase return on investment and time to market, while assuring higher quality and reliability than can be achieved through current software development. Numerous books and articles have been written about component-based development (CBD) and CBSE. Software Components have been produced and consumed by software organizations for several years. However common terms, such as software component, have been used by many authors and are ambiguously defined. The goal of component-based software engineering is to increase the productivity, quality, and time-to-market in software development thanks to the deployment of both standard components and production automation. One important paradigm shift implied here is to build software systems from standard components rather than "reinventing the wheel" each time. This requires thinking in terms of system families rather than single systems. CBSE uses Software Engineering principles to apply the same idea as OOP to the whole process of designing and constructing software systems. It focuses on reusing and adapting existing components, as opposed to just coding in a particular style. CBSE encourages the composition of software systems, as opposed to programming them. Early approaches to reusability have been adhoc. There hasnt been any standards adopted by the industry as a whole, and without standards, it has been difficult for developers to be motivated to design with reusability in mind. Increasingly, complex systems now need to be built with shorter amounts of time available. The buy, dont build approach is more important and popular than ever. Over the past decade, many people have attempted to improve software development practices by improving design techniques, developing more expressive notations for capturing a systems intended functionality, and encouraging reuse of pre-developed system pieces rather than building from scratch. Each approach has had some notable success in improving the quality, flexibility, and maintainability of application systems, helping many organizations develop complex, mission-critical applications deployed on a wide range of platforms. Q.8 Describe the spiral model?

"Waterfall Model" , most simple model designed and followed during software development process has its own disadvantages such as there is no fair division of phases in the life cycle, not all the errors/problems related to a phase are resolved during the same phase, instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase, this takes much of time of the next phase to solve them. The risk factor is the most important part, which affects the success rate of the software developed by following "The Waterfall Model".

In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it. This model is referred as "The Spiral Model" or "Boehms Model".

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and Engineering. These four phases are iteratively followed one after other in order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases. The phases in "Spiral Model" are: Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed
9

in order to decide which strategies/approaches to follow during the project life cycle. Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements. Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same. Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customers comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to TESTING phase. The process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration almost all possible risk factors, constraints, requirements are identified and in the next iterations all known strategies are used to bring up a complete software system. The radical dimensions indicate evolution of the product towards a complete system. However, as every system has its own pros and cons, "The Spiral Model" does have its pros and cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model", to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task. Q.9 Write a short note on COCOMO model

COCOMO (COnstructive COst MOdel) has been designed in 1981 by Barry Boehm to given an estimate of the number of man-months it will take to develop a software product and it is referred as COCOMO 81 A new model called COCOMO II was designed in 1990 and the need for this model came up as software development technology moved from mainframe and overnight batch processing to desktop development code re-usability and the use of off-the-shelf software components. COCOMO consists of a hierarchy of 3 increasingly detailed and accurate forms: 1) Basic COCOMO - is a static single valued model that computes software development effort and cost as a function of program size expressed in estimated lines of code 2) Intermediate COCOMO - computes software development effort as function of program size and a set of cost drivers that include subjective assessment of product hardware personnel and project attributes
10

3) Detailed COCOMO - incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step in SDLC Q.10 What are the characteristics of s/w process? Characteristic 1: Modularity Modularity is a key element of any good process. Modularity allows a process to be broken into components called activities. A software development process prescribes a set of activities capable of transforming the vision of the software system into reality. Activities are used in the agile software process like a good tool. They are to be wielded by software craftsman who know the proper circumstances for their use. They are not utilized to create a production-line atmosphere for manufacting software. Characteristic 2: Iterative Software processes acknowledge that we get things wrong before we get them right. Therefore, they focus on short cycles. Within each cycle, a certain set of activities is completed. These cycles will be started and completed in a matter of weeks. However, a single cycle (called an iteration) will probably not be enough to get the element 100% correct. Therefore, the short cycle is repeated many times to refine the deliverables. Characteristic 3: Time-Bound Iterations become the perfect unit for planning the software development project. We can set time limits (between one and six weeks is normal) on each iteration and schedule them accordingly. Chances are, we will not (unless the process contains very few activities) schedule all of the activities of our process in a single iteration. Instead, we will only attempt those activities necessary to achieve the goals set out at the beginning of the iteration. Functionality may be reduced or activities may be rescheduled if they cannot be completed within the allotted time period. Characteristic 4: Parsimony Processes are more than just a traditional software development process with some time constraints. Attempting to create impossible deadlines under a process not suited for rapid delivery puts the onus on the software developers. This leads to burnout and poor quality. Instead, agile software processes focus on parsimony. That is, they require a minimal number of activities necessary to mitigate risks and achieve their goals. By minimizing the number of activities, they allow developers to deliver systems against an aggressive schedule, while maintaining some semblance of a normal life. Characteristic 5: Adaptive During an iteration, new risks may be exposed which require some activities that were not planned. The process adapts the process to attack these new found risks. If the goal cannot be achieved using the activities planned during the iteration, new activities can be added to allow the goal to be reached. Similarly, activities may be discarded if the risks turn out to be ungrounded. Characteristic 6: Incremental Process does not try to build the entire system at once. Instead, it partitions the nontrivial system into increments which may be developed in parallel, at different times, and at different rates. We unit test each increment independently. When an increment is completed and tested, it is integrated into the system.
11

Characteristic 7: Convergent Convergence states that we are actively attacking all of the risks worth attacking. As a result, the system becomes closer to the reality that we seek with each iteration. As risks are being proactively attacked, the system is being delivered in increments. We are doing everything within our power to ensure success in the most rapid fashion. Characteristic 8: People-Oriented Processes favor people over process and technology. They evolve through adaptation in an organic manner. Developers that are empowered raise their productivity, quality, and performance. After all, they are the best individuals in the organization to know how to make these changes. Characteristic 9: Collaborative Processes foster communication among team members. Communication is a vital part of any software development project. When a project is developed in pieces, understanding how the pieces fit together is vital to creating the finished product. There is more to integration than simple communication. Quickly integrating a large project while increments are being developed in parallel, requires collaboration.

***

12