S. M. U.

BCA
Object Oriented Analysis and Design
BOOK ID B1010

Assignment 1

NAME - CHIRAG I. SHAH ROLL NO 511123683

Object Oriented Analysis and Design

Page 1

Q. A.

1. Explain the advantages of Object oriented systems. 1.

Object oriented systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater design and code reuse. 1) Higher level of abstraction, Top down approach supports abstraction at the function level. The object oriented approach supports abstraction at the object level. Since objects encapsulate both data and functions they work at a higher level of abstractions. 2) Seamless transition among different phases of software development, The object oriented approach essentially uses the same language to talk about analysis, design, programming and database design. This seamless approach reduces the level of complexity and redundancy and makes for clearer, more robust system development. 3) Encouragement of good programming techniques. In a properly designed system, the lasses will be grouped into subsystems but remain independent. Therefore, changing one class has no impact on other classes, and so, the impact is minimized which encourages good programming. 4) Promotion of reusability. Objects are reusable because they are modeled directly out of real world problem domain. The object orientation adds inheritance, which is a powerful techniques that allows classes to be built from each other and therefore, only differences and enhancements between the classes need to be designed and coded.

Object Oriented Analysis and Design

Page 2

Q. A.

2. Explain the Booch Methodology. 2.

The booch methodology is a widely used object oriented method that helps design system using the object paradigm. The booch method consists of the following diagrams. a) b) c) d) e) f) Class diagrams Object diagrams State transition diagrams Module diagrams Process diagrams Interaction diagrams

The booch methodology prescribes a macro development process and a micro development process.
Car Color Manufacturer cost

Superclass

Ford

Mustang

Taurus

Escort

Object modeling using booch notation. The arrows represent specialization; for example, class Taurus is subclass of the class Ford. a) The Macro development process :- The macro process serves as a controlling framework for the micro process and can take weeks or even months. The macro development process consists of the following steps: a. Conceptualization : During conceptualization, you establish the core requirements of the system. You establish a set of goals and develop a prototype to prove the concept. b. Analysis and development of the model : In this step, you use the class diagrams to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system. Then you use the object diagram to describe the desired behavior of the system in terms of scenarios or alternatively, use the interaction diagram to describe behavior of the system in terms of scenarios. c. Design or create the system architecture : In the design phase, you use the class diagram to decide what classes exist and how they relate to each other. Next, you use the object diagram to decide what mechanisms are used to regulate how objects collaborate. Then you use the module diagram to map out where each class and object should be declared. Finally, you use the process diagram to determine to which processor to allocate a process. Also, determine the schedules for multiple processes on each relevant processor.

Object Oriented Analysis and Design

Page 3

d. Evolution or implementation : Successively refine the system through much iteration. Produce a stream of software implementations each of which is a refinement of the prior one. e. Maintenance : make localized changes to the system to add new requirements and eliminate bugs. b) The micro development process :- Each macro development process has its own micro development processes. The micro development process consists of the following steps: a. b. c. d. Identify Identify Identify Identify classes and objects. class and object semantics. class and object relationships. class and object interfaces and implementation.

Object Oriented Analysis and Design

Page 4

Q. A.

3. Justify that UML is a language for modeling, visualizing, specifying, constructing, and documenting. 3.

The Unified Modeling Language or the UML, is a graphical modeling language that provides us with syntax for describing the major elements of software systems. The uml is gaining adoption as a single, industry wide language. The UML is a language for modeling, visualizing, specifying, constructing and documenting the artifacts of a software intensive system. 1) The UML is a Language for Modeling A language provides a vocabulary and the rules for combining words in that vocabulary for the purpose of communication. A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language such as the UML is thus a standard language for software blueprints. The vocabulary and rules of a language such as the UML tell you how to create and read well formed models. But they dont tell you what models you should create and when you should create them. Thats the role of the software development process. A well defined process will guide you in deciding what artifacts to produce, what activities and what workers to use them, create them and manage them, and how to use those artifacts to measure and control the project as whole. 2) The UML is a Language for Visualizing : The UML is more than just a bunch of graphical symbols. Rather, behind each symbol in the UML notation is a well defined semantics. One developer can write a model in the UML and another developer or even another tool, can interpret that model unambiguously. Some things are best modeled textually; others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. Using U Some things are best modeled textually; others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. Using UML you can produce explicit models that facilitate communication. The UML is a Language for Specifying : In this context, specifying means building models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made in developing and deploying a software intensive system. The UML is a Language for Constructing : The UML is not a visual programming language, but its models can be directly connected to a variety of programming languages. It is possible to map from a model in the UML to a programming language such as java, c++ or visual basic or even to tables in a relational database or persistent store of an object-oriented database. This mapping permits forward engineering. The generation of code from a UML model into a programming language. The reverse is also possible.

3)

4)

Object Oriented Analysis and Design

Page 5

5)

The UML is a Language for Documenting : A healthy software organization produces all sorts of artifacts in addition to raw executable code. These are ,,,, a. b. c. d. e. f. g. h. Requirements Architecture Design Source code Project plans Tests Prototypes Releases

Depending on the development culture, some of these artifacts are treated more or less formally than others. Such as artifacts are not only the deliverables of project, they are also critical in controlling, measuring and communicating about a system during its development and after its deployment. The UML addresses the documentation of a systems architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management.

Object Oriented Analysis and Design

Page 6

Q. A.

4. What are the potential advantages of treating two related classes as subclasses of some super class? 4. Star Foundation Case Study

The second step is class modeling. The aim of this step is to extract the entity classes, determine their interrelationships, and find their attributes. The best way to start this step is usually to use the two-stage noun extraction method. In stage 1 we describe the information system in a single paragraph. In the case of the STAR Foundation case study, a way to do this is, Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on demand. In stage 2 we identify the nouns in this paragraphs. For clarity, the nouns are printed in bold. Weekly reports are to be printed showing how much money is available for mortgages. In addition, lists of investments and mortgages must be printed on demand. The nouns are report, money, mortgage, list and investment. Nouns report and list are not long lived, so they are unlikely to be entity classes and money is an abstract noun. This leaves two candidate entity classes, namely mortgage class and investment class. We consider interaction between these two entity classes. Looking at the descriptions of use cases manage an investment and manage a mortgage it appears that the operation performed on the two entity classes are likely to be very similar, namely, insertions, deletions, and modifications. Also, the second iteration of the description of use case produce a report. Shows all the members of both entity classes have to be printed on demand. In other words, Mortgage Class and Investment Class should probably be subclasses of some superclass. We will call that superclass asset class. Because mortgages and investments are both assets of the STAR Foundation.

Object Oriented Analysis and Design

Page 7

Q. A.

5. How is responsibility-driven design used as a guide for deciding how to allocate operations to classes? 5.

Class-responsibility-collaboration (CRC) cards have been utilized during objectoriented analysis and design. For each class the information system development team fills in a card showing the name of the class, the functionality of that class and a list of the other classes it invokes in order to achieve that functionality. CRC cards were originally introduced as a tool for performing requirements elicitation and analysis. CRC cards are indeed a powerful tool for this purpose, but only when the information technology professionals are familiar with the domain; that is, the specific business environment in which the information system is to operate, such as aerospace, banking or cloth manufacturing. However even for information technology professionals who have do domain expertise whatsoever, CRC cards are an extremely effective way of testing object oriented analysis and design artifacts. An example of a CRC cards is shown in fig. the data for this figure are obtained from the realization of all the use cases of the START Foundation case study. Request estimated grants and payments for week is passed from Estimate funds for week class to mortgage class, followed by message , Return estimated grants and payments for week in the reverse direction. We conclude that mortgage class has the responsibility compute estimated grants and payments for week and, in order to do this, must collaborate with Estimate funds for week class. This is reflected in the first entry in the CRC card.

CLASS Mortgage Class RESPONSIBILITY Compute estimated grants and payments for week Initialize, update and delete mortgages Generate list of mortgages Print list of mortgages COLLABORATION Estimate Funds for Week Class Manage an Asset Class User interface Class Mortgages Report Class

Object Oriented Analysis and Design

Page 8

Q. A.

6. Explain the five core workflows of the Unified Process 6. 1) The Requirements Workflows. The aim of the requirements workflow is to ensure that the developers build the right information system. This is achieved by describing the target information system sufficiently clearly and accurately that the two main stakeholders, the client and the developers, can agree on what the information system should do and should not do. In order to achieve this the requirements have to be fully understood by the client. One way to achieve this is to use the Unified Process; the many models of the Unified Process assist the client in gaining the necessary detailed understanding of what is to been developed. 2) The Analysis Workflows. The purpose of the analysis workflow is to analyze and refine the requirements. By doing this we achieve the detailed understanding of the requirements that we must have to develop an information system correctly and to maintain it easily. But why do we have an analysis workflow at all ? surely it would be simpler to develop an information system by continuing with further iterations of the requirements workflow until we obtain the necessary understanding of the target information system. The key point is that the output of the requirements workflow be totally comprehensible by the client. In other words, the artifacts of the requirements workflow must be expressed in the language of the client, that is, in a natural language such as English, Armenian, or zulu. But all natural languages without exception are somewhat imprecise and lend themselves to misunderstanding. A part record and a plant record are read from the databases. If it contains the letter a directly followed by the letter q, then calculate the cost of transporting that part to that plant. At first sight, this requirement seems perfectly clear. But to what does the it refer ? The part record ? The plant record ? or the databases ? Ambiguities of this kind cannot arise if the requirements are expresses in a mathematical notation. However, if a mathematical notation is used for the requirements, then client is unlikely to understand much of the requirements artifacts. Consequently, the information system developed to satisfy these requirements may not be what the client needs. The solution is to have two separate workflows. The requirements workflow is couched in the language of the client. The analysis workflow is a more precise language that will ensure that the design and implementation workflow are correctly carried out. In addition, more details are added during the analysis workflow, details that are not relevant to the clients understanding o f the target information system but are essential for the information technology professionals who will develop the information system. Consider, for example, the initial state of a statechart. This is entirely irrelevant from the viewpoint of the client. However it is essential to specify the initial state for the information technology professionals so that they can implement the statechart correctly. 3) The design Workflow. During the design workflow we refine the analysis workflow until the material is in a form that can be implemented by the programmers. In addition, a number of requirements need to be finalized at this

Object Oriented Analysis and Design

Page 9

time, including choice of programming language, as well as reuse and portability issues. 4) The Implementation Workflow. The aim of the implementation workflow is to implement the target information system in the selected implementation language. More precisely, a large information system is portioned into smaller subsystems, which are then implemented in parallel by coding teams. The subsystems, in turn, consist of components or code artifacts. As soon as a component has been coded, the programmer tests it. Once the programmer is satisfied that the component is correct, it is passed onto the quality assurance group for further testing. 5) The Test Workflow. The test workflow is the responsibility of the quality assurance group. As pointed out the end of the previous section, each component is tested by the quality assurance group as soon as it has been implemented; this is termed unit testing. At the end of each iteration, integration testing is performed. Here, the components that have been completed and unit tested are complied and linked together and then tested against various test cases. When the product appears to be complete, it is tested as whole this is termed product testing. When management believes that the product is fault free it is installed on the clients computer. The client now performs acceptance testing. That is, the client checks whether the delivered information system satisfies its specifications. If the information system passes the acceptance test, the client pays the developers. If not the developers have to fix the information system until it passes the acceptance test.

Object Oriented Analysis and Design

Page 10

S. M. U.
BCA
Object Oriented Analysis and Design
BOOK ID B1010

Assignment 2

NAME - CHIRAG I. SHAH ROLL NO 511123683

Object Oriented Analysis and Design

Page 11

Q. A.

1. Discuss the importance of object orientation during system development. 1.

Object oriented system are easier to adapt to changing requirements, easier to maintain, more robust and promote greater design and code reuse. 1) Higher level of abstraction. Top-down approach supports abstraction at the function level. The objet oriented approach supports abstraction at the object level. Since objects encapsulate both data and functions they work at a higher level of abstraction. 2) Seamless transition among different phases of software development. The object-oriented approach essentially uses the same language to talk about analysis, design, programming and database design. This seamless approach reduces the level of complexity and redundancy and makes for clearer, more robust system development. 3) Encouragement of good programming techniques. In a properly designed system, the classes will be grouped into subsystems but remain independent. Therefore, changing one class has no impact on other classes, and so, the impact is minimized which encourages good programming. 4) Promotion of reusability. Objects are reusable because they are modeled directly out of real-world problem domain. The object orientation adds inheritance, which is a powerful technique that allows classes to be built from each other and therefore, only differences and enhancements between the classes need to be designed and coded.

Object Oriented Analysis and Design

Page 12

Q. A.

2. What is polymorphism ? Explain it with one example. 2.

Poly means many and morph means form. In the context of object oriented system, it means objects that can take on or assume many different forms. Polymorphism means that the same operation many behave differently on different classes. Polymorphism allows us to write generic, reusable code more easily, because we can specify general instructions and delegate the implementation details to the objects involved. Since no assumption is made about the class of an object that receives a message, fewer dependencies are needed in the code and, therefore maintenance is easier. In a payroll system manager, office worker and production worker objects all will respond to the compute payroll message but the actual operations performed are object specific.

Object Oriented Analysis and Design

Page 13

Q. A.

3. Explain the various tools for software implementation. 3.

CASE Tools:Computer Aided Software Engineering (CASE) tolls allow their users to rapidly develop information system. The main goal of CASE technology is the automation of the entire information systems development life cycle process using a set of integrated software tools, such as modeling, methodology, and automatic code generation. However most often, the code generated by CASE tools is only the skeleton of an application and a lot needs to be filled in by programming by hand. A new generation of CASE tools is beginning to support Component Base Development. Component Base Development:- CBD is an industrialized approach to the software development process. Application development moves from custom development to assembly of prebuilt, pretested, reusable software components that operate with each other. Two basic ideas underlie component based development. first, the application development can be improved significantly if applications can be assembled quickly from prefabricated software components. Second an increasingly large collection of interpretable software components could be made available to developers in both general and specialist catalogs. Put together, these two ideas move application development from a craft activity to an industrial process fit to meet the needs of modern, highly dynamic, competitive, global businesses. Software Components:The software components are the functional units of a program, building blocks offering a collection of reusable services. A software component can request a service from another component or deliver its own services on request. The delivery of services is independent which means that components work together to accomplish a task. In short the object oriented concept addresses analysis design and programming whereas component based development is concerned with the implementation and system integration aspects of software development. Rapid Application Development:- RAD is a set of tools and techniques that can be used to build an application faster than typically possible with traditional methods. The term often is used in conjunction with software prototyping. RAD does not replace the system development life cycle but complements it, since it focuses more on process description and can be combined perfectly with the object oriented approach. The task of RAD is to build the application quickly and incrementally implement the design and user requirements, through tools such as Delphi, Visual age, Visual Basic, or Power Builder. Incremental testing:If you wait until after development to test an application for bugs and performance, you could be wasting thousands of dollars and hours of time. Testing should be an integral part of SDLC.

Object Oriented Analysis and Design

Page 14

Q. A.

4. Explain the Jacobson et al. methodologies. 4.

The Jacobson et al. methodologies cover the entire life cycle and stress traceability between the different phases, both forward and backward. Use Cases:Use cases are scenarios for understanding system requirements. A use case is an interaction between users and a system. The use-case model captures the goal of the user and the responsibility of the system to its users. In the requirements analysis, the use cases are described as one of the following: Non-formal text with no clear flow of events Text, easy to read but with a clear flow of events to follow (this is a recommended style) Formal style using pseudo code

The use case description must contain: How and when the use case begins and ends The interaction between the use case and its actors, including when the interaction occurs and what is exchanged How and when the use case will need data stored in the system or will store data in the system Exceptions to the flow of events How and when concepts of the problem domain are handled.

Every single use case should describe one main flow of events. An exceptional or additional flow of events could be added. The exceptional use case extends another use case to include the additional one. The use case model employs extends and uses relationships. The extends relationship is used when you have one use case that is similar to another use case but does a bit more. In essence, it extends the functionality of the original us case. The uses relationship reuses common behavior in different us cases. Use cases could be viewed as concrete or abstract. An abstract use case is not complete and has no actors that initiate it but is used by another use case. This inheritance could be used in several levels. Abstract use cases also are the ones that have uses or extends relationships. Object-Oriented Software Engineering: Objectory Object-Oriented software engineering (OOSE) also called Objectory, is a method of object oriented development with the specific aim to fit the development of large, real time systems. Objectory is built around several different models: Use case model- The use case model defines the outside and inside of the systems behavior. Domain object model- The object of the real world are mapped into the domain object model.

Object Oriented Analysis and Design

Page 15

Analysis object model- The analysis object model presents how the source code should be carried out and written. Implementation modelThe implementation model represents the implementation of the system. Test model- The test model constitutes the test plans, specification, and reports.

Object-Oriented Business Engineering OOBE is object modeling at the enterprise level. Analysis phase. The analysis phase defines the system to be built in terms of the problem domain object model, the requirements model, and the analysis model. The analysis process should not take into account the actual implementation environment. This reduces complexity and promotes maintainability over the life of the system, since the description of the system will be independent of hardware and software requirements. Design and implementation phases. The implementation environment must be identified for the design model. This includes factors such as DBMS distribution of process, constraints due to the programming language, available component libraries, and incorporation of graphical user interface tools. Testing phase. Finally, Jacobson describes several testing levels and techniques. The levels include unit testing, integration testing and system testing.

Object Oriented Analysis and Design

Page 16

Q. A.

5. Justify that UML is a language for modeling, visualizing, specifying, constructing, and documenting. 5.

The Unified Modeling Language or the UML, is a graphical modeling language that provides us with syntax for describing the major elements of software systems. The uml is gaining adoption as a single, industry wide language. The UML is a language for modeling, visualizing, specifying, constructing and documenting the artifacts of a software intensive system. 1) The UML is a Language for Modeling A language provides a vocabulary and the rules for combining words in that vocabulary for the purpose of communication. A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language such as the UML is thus a standard language for software blueprints. The vocabulary and rules of a language such as the UML tell you how to create and read well formed models. But they dont tell you what models you should create and when you should create them. Thats the role of the software development process. A well defined process will guide you in deciding what artifacts to produce, what activities and what workers to use them, create them and manage them, and how to use those artifacts to measure and control the project as whole. 2) The UML is a Language for Visualizing : The UML is more than just a bunch of graphical symbols. Rather, behind each symbol in the UML notation is a well defined semantics. One developer can write a model in the UML and another developer or even another tool, can interpret that model unambiguously. Some things are best modeled textually; others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. Using U Some things are best modeled textually; others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. Using UML you can produce explicit models that facilitate communication. The UML is a Language for Specifying : In this context, specifying means building models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made in developing and deploying a software intensive system. The UML is a Language for Constructing : The UML is not a visual programming language, but its models can be directly connected to a variety of programming languages. It is possible to map from a model in the UML to a programming language such as java, c++ or visual basic or even to tables in a relational database or persistent store of an object-oriented database. This mapping permits forward engineering. The generation of code from a UML model into a programming language. The reverse is also possible.

3)

4)

Object Oriented Analysis and Design

Page 17

5)

The UML is a Language for Documenting : A healthy software organization produces all sorts of artifacts in addition to raw executable code. These are, a. b. c. d. e. f. g. h. Requirements Architecture Design Source code Project plans Tests Prototypes Releases

Depending on the development culture, some of these artifacts are treated more or less formally than others. Such as artifacts are not only the deliverables of project, they are also critical in controlling, measuring and communicating about a system during its development and after its deployment. The UML addresses the documentation of a systems architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management.

Object Oriented Analysis and Design

Page 18

Q. A.

6. Explain State charts and Activity Diagrams with Examples. 6.

A state chart diagram shows a state machine, consisting of states, transitions, events and activities. State chart diagrams address the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-order behavior of an object, which is especially useful in modeling reactive systems.

Off

Red

Red/Amber

Green

Amber
Activity Diagram An Activity Diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects. Fork Write down order

Prepare Chicken

Prepare Fish

Join

Serve order

Object Oriented Analysis and Design

Page 19