Object simplied tools PDF

Preview

Summary

Object Oriented Systems Designs...

Description

i.

What is the Object Modeling Techniques (OMT)..

The object-modeling technique (OMT) is an object modeling approach for software modeling and designing. It was developed around 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented systems and to support object-oriented programming. Describes Object model or static structure of the system. OMT was developed as an approach to software development. The purposes of modeling according to Rumbaugh are: •

Testing physical entities before building them (simulation),

•

Communication with customers,

•

Visualization (alternative presentation of information), and

•

Reduction of complexity.

OMT has proposed three main types of models: • Object Model • Dynamic Model • Functional Model ii.

What is the role of Swim lanes & Guard condition in Activity diagram. Swimlanes: • • •

Swimlanes (or activity partitions) indicate where activities take place. Swimlanes can also be used to identify areas at the technology level where activities are carried out Swimlanes allow the partition an activity diagram so that parts of it appear in the swimlane relevant to that element in the partition

Guard Conditions: You can add a guard condition to an activity edge between two nodes, where the guard condition defines a condition that must be satisfied before the target activity node can be invoked. You can define the guard condition in the following ways: • •

name [guard condition] - The guard condition is created and is assigned a name. [guard conditon] - The guard condition is created, but is not assigned a unique name.

In the following figure, one activity node called OpaqueAction is connected to a second activity node, called OpaqueAction2. A guard condition, called Guard1, specifies that the value of g coming from OpaqueAction must be greater than 10 for OpaqueAction2 to be invoked.

iii. Explain the different among Bidirectional, Unidirectional & Reflexive Association. An association is a relationship between two classes represented by a solid line. Associations are bi-directional by default, so both classes know about each other and about the relationship between them. Either end of the line can have a role name and multiplicity. In the example, Student has the role of "tenant" in relation to Apartment and Apartment has the role of "accommodation" in relation to Student. Also, any instance of Apartment can be associated with up to four students and any student could be associated with 0 or 1 Apartment (a student either has an apartment to live in or does not).

Associations can also be unidirectional, where one class knows about the other class and the relationship but the other class does not. Such associations require an open arrowhead to point to the class that is known and only the known class can have a role name and multiplicity. In the example, the Customer class knows about any number of products purchased but the Product class knows nothing about any customer. The multiplicity "0..*" means zero or more.

An alternative to using role names is to provide a single name for an association centered between the two classes. A direction indicator can also be used to show the direction of the name, but is not necessary if the direction is obvious:

An association can also link a class to itself. Such an association is reflexive:

iv. Compare OOAD & SSAD. SSAD (Structured Analysis): In Structured Analysis, the focus is only on process and procedures. Modeling techniques used in it are DFD(Data Flow Diagram), Flowcharts etc. This approach is old and is not preferred.

OOAD (Object Oriented Analysis ): Whereas in Object Oriented Analysis, the focus is more on capturing the real world objects in the current scenario that are of importance to the system. It stresses more on data structure and less on procedural structure. Without actually identifying objects, what are you going to interact with, and whose state will you change. In this approach, objects are identified, their relationships among each other, possible states that each object can be in, and finally how all objects collaborate with each other to achieve a broader system goal are identified. v. Explain the term OORASS & HOOD. The Object Oriented Role Analysis and Modeling (OOram) is a method, based on the concept of role, for performing object-oriented modeling. Originally (1989) coined Object Oriented Role Analysis, Synthesis and Structuring (OORASS), the method focuses on describing patterns of interaction without connecting the interaction to particular objects/instances. OOram was originally developed by Trygve Reenskaug (1996), a professor at the University of Oslo and the founder of the Norwegian IT company Taskon. HOOD: Hierarchical Object-Oriented Design (HOOD) has been developed for the European Space Agency as a design/notation method for Ada. Robinson introduces it in this way: "The top-down hierarchical decomposition approach is not new. After all, this is the method used with data flow diagrams starting from a context diagram which shows all the external interfaces with one central process. This process is then decomposed into other processes with data flows and control flows interacting between them, with consistency checks between levels. In the same way, the purpose

of HOOD is to develop the design as a set of objects which together provide the functionality of the program." The phases can be summarized as follows: •

• •

•

Problem definition. o Statement of the problem - the designer states the problem in correct sentences which provides: o Analysis and structuring of requirement data Development of solution strategy. Formalization of the strategy. o Objet identification. o Operation identification. o Grouping objects and operations (object operation table). o Graphical description. o Justification of design decisions. Formalization of the solution.

vi. Discuss different goals of UML. A picture is worth a thousand words, this absolutely fits while discussing about UML. Object oriented concepts were introduced much earlier than UML. So at that time there were no standard methodologies to organize and consolidate the object oriented development. At that point of time UML came into picture. There are a number of goals for developing UML but the most important is to define some general purpose modeling language which all modelers can use and also it needs to be made simple to understand and use. UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. The system can be a software or non software. So it must be clear that UML is not a development method rather it accompanies with processes to make a successful system. At the conclusion the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.

vii.

Difference between class notation and object notation in UML.

Class Notation: UML class is represented by the diagram shown below. The diagram is divided into four parts.

• • • •

The top section is used to name the class. The second one is used to show the attributes of the class. The third section is used to describe the operations performed by the class. The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.

Object Notation: The object is represented in the same way as the class. The only difference is the name which is underlined as shown below. As object is the actual implementation of a class which is known as the instance of a class. So it has the same usage as the class.

viii.

Difference between test strategy and test plan.

Test Strategy: A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document. Components of the Test Strategy document Scope and Objectives Business issues Roles and responsibilities Communication and status reporting Test deliverability Industry standards to follow Test automation and tools Testing measurements and metrics Risks and mitigation Defect reporting and tracking Change and configuration management Training plan

• • • • • • • • • • • •

Test Plan: The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents. The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.

ix.

Generalization & Specialization

Generalization is the process of extracting shared characteristics from two or more classes, and combining them into a generalized super class. Shared characteristics can be attributes, associations, or methods. In contrast to generalization, specialization means creating new subclasses from an existing class. If it turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a subclass can be created. The most inclusive class in a generalization/specialization is called the super class The more specific classes are called subclasses and are generally placed below the super class. x.

Difference between sequence diagram and collaboration diagram

Sequence Diagram: A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from

one object to another. Interaction among the components of a system is very important from implementation and execution perspective. So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality. Collaboration Diagram: Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links. The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.

Q2(a). What is Unified Process Model? Explain the iterations, outcomes & Workflow in unified Process Model with neat diagram. Unified process (UP) is an architecture-centric, use-case driven, iterative and incremental development process that leverages unified modeling language and is compliant with the system process engineering meta model. Unified process can be applied to different software systems with different levels of technical and managerial complexity across various domains and organizational cultures. UP is also referred to as the unified software development process. Iteration: A typical iteration crosses all five of the workflows discussed in the previous section, to a greater or lesser extent. For instance, an iteration during the Elaboration phase might focus heavily on activities of the Requirements and Analysis workflows, whereas an iteration during Construction is more likely to involve Design, Implementation, and Test activities. Each iteration results in an increment. This is a release of the system that contains added or improved functionality compared with the previous release. Figure below shows the essence of the iterative and incremental approach to software development.

Then the team follows these steps: 1. Define the first iteration, addressing the most critical and difficult risks. 2. Map out a plan for the iteration to a suitable level of detail. 3. Perform the appropriate activities; for the Unified Process, these are activities associated with the Requirements, Analysis, Design, Implementation, and Test workflows. 4. Do a postmortem on the increment that results from the iteration. 5. Discard the risks that the increment has sufficiently addressed. Then update the ongoing risk list. 6. Revise the overall project plan in response to the relative success or failure of the iteration. 7. Proceed with the next iteration. The Five Workflows: Within the Unified Process, five workflows cut across the set of four phases: Requirements, Analysis, Design, Implementation, and Test. •

Requirements The primary activities of the Requirements workflow are aimed at building the use case model, which captures the functional requirements of the system being defined. This model helps the project stakeholders reach agreement on the capabilities of the system and the conditions to which it must conform.

• Analysis The primary activities of the Analysis workflow are aimed at building the analysis model, which helps the developers refine and structure the functional requirements captured within the use case model. This model contains realizations of use cases that lend themselves to design and implementation work better than the use cases. • Design

The primary activities of the Design workflow are aimed at building the design model, which describes the physical realizations of the use cases from the use case model, and also the contents of the analysis model. The design model serves as an abstraction of the implementation model • Implementation The primary activities of the Implementation workflow are aimed at building the implementation model, which describes how the elements of the design model are packaged into software components, such as source code files, dynamic link libraries (DLLs), and EJBs.

Q 2(b). Write a short note on “Object-Oriented Software Life Cycle. The software life-cycle: • • •

Analysis -- Conceptual Model, System Requirements Design -- System Design, Detailed Design Implementation -- Coding, Testing

Software development models The software engineering literature abounds with descriptions of failing software projects and remedies proposed to solve the problem of software not meeting user expectations. Software development models • • • • •

rapid throwaway prototyping -- quick and dirty incremental development -- slowly evolving evolutionary prototyping -- evolving requirements reusable software -- reduces cost and time automated software synthesis -- one level of abstraction higher

Requirements -- user needs are constantly evolving • • • •

Reliability -- incremental development, reuse, synthesis Adaptability -- evolutionary prototyping Maintainability -- incremental development, synthesis Performance -- incremental development, reuse

Q3(a). Write a short note on Object-Oriented Modeling Technique. Modeling as a set of techniques for expressing the target system before the target system has been complete. Using these techniques, we will build a model of the target system. The model will express various aspects of the system to be developed. The representation chosen for

communicating the model is a notation. The necessity of building models may be rationalized in a number of ways. One reason for modeling is to support the building of software systems whose complexities exceed our mental capacities. For example, most of us are unable to multiply multidigit numbers together in our heads, but with the aid of a pencil and paper the task is trivial. Our unaided mental capacity has limitations, which can be augmented by techniques that allow us to record previous thinking. Such augmentation permits the shifting of our mental focus to unsolved portions of the problem. We will use a software engineering notation to record previous analysis and design decisions so that we may focus on new areas of the software system. Model building addresses the complexity of the system to be developed by facilitating the creation of a series of models. The first model begins with an abstract representation of the system. Later models contain progressively more detail. Subsequent models are made to contain more detail than their predecessor models by focusing on a smaller portion of the system and extending the analysis to produce additional depth in that portion. The process of model building, therefore parallels the system developers’ understanding of the system. As the system analysts begin their study of the target system, their understanding is very general. During the modelbuilding process, the models become increasingly detailed, and the system developers’ understanding also increases. Modeling software systems also creates concise and unambiguous representations, which facilitate communication between collaborating system developers. These precise representations can also be evaluated, verified, and corrected before significant time is invested in programming a poorly conceptualized system.

Q3(b). Discuss the qualities of Object-Oriented techniques. The primary objective of applying good software engineering practices to a software project is to produce quality software in a timely, predictable manner. The second question is “Are the objectives of object-oriented software engineering any different from those of the processoriented software approach?” A feature that distinguishes object-oriented software development projects from process-oriented projects is that object-oriented development emphasizes the ability of the software to evolve smoothly over each software release. This emphasis implies that the software is easily extensible. The Object-oriented development also emphasizes modularity, but the modules must also evolve easily. Extensibility of modules is, therefore, an objective of object-oriented development and is a quality of a good software system. . The desire for reusable software modules transcends the particular choice of software development approach. Certain mechanisms, however, are particularly conducive to the creation of reusable code. Many of these mechanisms are available in object-oriented programming languages. In particular, the inheritance mechanism, unique to object-oriented systems, suggests a strategy for software module reuse. The common code in the parent classes is used over and over (as inherited methods and attributes) in the child classes. Thinking of inheritance in this manner suggests that optimal use of inheritance hierarchies is another quality of a good object-oriented software system.

Q6(a). Discuss object-oriented testing stretegies in detail. • Object-Oriented Testing Strategies: 1. Unit testing in the OO context: • • • • •

Smallest testable unit is the encapsulated class or object Similar to system testing of conventional software Do not test operations in isolation from one another Driven by class operations and state behavior, not algorithmic detail and data flow across module interface Complete test coverage of a class involves ▪ ▪ ▪

•

Design of test for a class uses a verity of methods: ▪ ▪ ▪

• • •

Testing all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states

fault-based testing random testing partition testing

each of these methods exercises the operations encapsulated by the class test sequences are designed to ensure that relevant operations are exercised state of the class (the values of its attributes) is examined to determine if errors exist

2. Integration testing in the OO context • • • • • • •

focuses on groups of classes that collaborate or communicate in some manner integration of operations one at a time into classes is often meaningless thread-based testing (testing all classes required to respond to one system input or event) use...