M.A.M. COLLEGE OF ENGINEERING, TIRUCHIRAPPALLI 621 105
M.A.M. COLLEGE OF ENGINEERING, TIRUCHIRAPPALLI 621 105 QUESTION BANK – JULY 2013 - VII SEMESTER CSE CS1310- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I PART A 1. What is meant by Object Oriented? What are advantage of object oriented development? Object Oriented means we organize the software as a collection of discrete objects that incorporate both data structure and behavior. Advantage of OO Development • High level of abstraction • Seamless transition among different phases of software development • Encouragement of good programming techniques. • Promotion of reusability. 2. Write the characteristics of an object. Identity Classification Polymorphism and Inheritance. 3. What is dynamic binding and static binding? Dynamic binding The process of determining (dynamically) at run time which functions to invoke is termed dynamic binding. Static binding The process of determining at compile time which functions to invoke is termed static binding. 4. Write the four quality measures for software development? Correspondence Correctness Verification and Validation. 5. What is object persistence? Objects have life time. They are created and can exist for a period of time. Traditionally, it has been the duration of the process in which they were created. A file or database can provide support for objects having a longer lifeline longer than the duration of the process for which they were created. This characteristics called object persistence. 6. What is cardinality? Cardinality specifies how many instances of one class may relate to a single instance of an associated class. 7. What is a meta-class? A meta-class is a class about a class. They are normally used to provide instance variables and operations. 8. What are orthogonal views of software? Object oriented development methods differ from traditional development techniques in that the traditional techniques view software as a collection of programs and isolated data. Algorithm + data = programs It primarily focus on functions or data. Object oriented methodology centers on objects which combines data and functionality. 9. Distinguish between method and message in object. Method and Message i) Methods are similar to functions, procedures or subroutines in more traditional programming languages. Message essentially are non-specific function calls. ii) Method is the implementation. Message is the instruction. iii) In an object oriented system, a method is invoked by sending an object a message. An object understands a message when it can match the message to a method that has the same name as the message. 10. What are the primary goals in the design of UML? • Provide extensibility and specialization mechanism to extend the core concepts. • Be independent of particular programming language and development process. • 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. PART B 1. Briefly explain about object oriented system development (OOSD) life cycle. Object Oriented Systems Development Life Cycle Goals The software development process Building high-quality software Object-oriented systems development Use-case driven systems development Prototyping Rapid application development Component-based development Continuous testing and reusability The Software Development Process System development can be viewed as a process. The development is a process of change, refinement, transformation or addition to existing product. The process can be divided into small, interacting phases in to sub process. The sub processes must be defined in such a way to allow each activity to be performed as independently of other sub process as possible. Each sub processes must have the following A description in terms of how it works Specification of the input required for the process. Specification of the output to be produced. The software development process also can be divided into smaller, interacting sub processes. It can be viewed as a series of transformation. Transformation 1(analysis) translates the users need into system requirements and responsibilities. It provide insight into the users requirements. Transformation2(design) begins with a problem statement and ends with a detailed design that can be transformed into operational system. It includes software development activity, definition of how to build the software, its development and testing. What How Do it Test Use FIG Software process reflecting transformation from needs to a software product that satisfy those needs Transformation 3(Implementation) refines the detailed design into the system deployment that will satisfy the user needs. The essence of the software process is the transformation of Users‘ needs to The application domain into A software solution. As an example of software development process is the water fall approach which starts with deciding what is to be done. Once the requirement has been determined, next must decide how to accomplish them. This is followed by a step in which “do it. We then must “test’ the result to see if we have satisfy the user requirements. System and programming changes in this approach, make the process increasingly complex, since each request must be considered in regard to the original statement of needs as modified by other requests. Building High Quality Software There are two basic approaches to systems testing. We can test a system according to how it has been built. Alternatively, we can test the system with respect to what it should do. Quality Measures Systems can be evaluated in terms of four quality measures Correspondence Correctness Verification Validation Correspondence measures how well the delivered system matches the needs of the operational environment as described in the original requirement statement. Validation is the task of predicting correspondence. Correctness measures the consistency of the product requirement with respect to the design specification. Verification is the exercise of correctness. Validation Verification Needs Requirements Correctness Correspondence Design Softwrae Object Oriented System Development: A Use-case driven Approach The object oriented software development life cycle consists if three macro process: Build a Use-case Model Object Analysis Analysis Validate/ Test Iteration and Reuse Using TOOLS CASE and /or OOP Programming Languages User satisfaction usability and QA Test Design Classes, Define attributes and methods Implementation Build object & dynamic Model Design Fig : Object oriented System Development Approach Object oriented development Consists of three macro processes Object- oriented Analysis Object oriented Design Object-Oriented Systems has the following development activities Object-oriented analysis. Object-oriented design. Prototyping. Component-based development. Build user interface & Prototype User satisfaction Test, usability test, QA Test Incremental testing. Object-Oriented Analysis OO analysis concerns with determining the system requirements and identifying classes and their relationships that make up an application. Object-oriented design The goal of object-oriented design (OOD) is to design the classes identified during the analysis phase and the user interface. During this interface we identify and define additional objects and classes that support implementation of the requirements. First build the object model based on object and their relationship, then iterate and refine the model. Design and refine classes Design and refine attributes Design and refine methods Define and refine structures Define and refine association. Few guideline to use object oriented design Reuse rather than build, a new class. Know the existing class.Design a large number of simple classes, rather than a small number of complex classes. Prototype A Prototype enables you to fully understand how easy or difficult it will be to implement some of the features of the system. It can also give users a chance to comment on the usability and usefulness of the design. Types of Prototypes Horizontal prototype is a simulation of the interface but contain no functionality. This has the advantage of being very quick to implement ,providing a good overall feel of the system and allowing users to evaluate the interface on the basis of their normal expected perception of the system. Vertical Prototype is a subset of the system features with complete functionality. The advantage of this methods is that the few implemented functions can be tested in grate depth. Analysis prototype is a aid for exploring the problem domain. This class of prototype is used to informs the user and demonstrate the proof of concept. Domain prototype is a aid for the incremental development of the ultimate software solution It often used as the tools for staged delivery of the subsystem to the users or other members of the development team. Implementation: Component based development Component base development is an industrial approach to the software development process. Application development moves from custom development to assembly of prebuilt, pretested, reusable software component that operate with each other. The basic ideas underlie component based development. First the application development can be improved significantly if application can be assembled quickly from prefabricated software compacts. Second an increasingly large collection of interpretable software component could be made available to developers in both general and specialist catalogues. Rapid application development 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. Incremental Testing If wait until after development to test an application for bugs and performance could be wasting thousands of dollars and hours of time. The problem was the developer would turn over application to a quality assurance group for testing only after development was completed. 2. Explain the following (i). Class hierarchy (8) CLASS HIERARCHY A n object oriented system organize classes into a subclass, super class hierarchy. Different properties and behaviors are used as the basis for making decision between classes and subclasses. At the top of the class hierarchy are most general classes and at the bottom are the more specific. The family car in a figure is a sub classes of a car. A subclasses inherits all of the property and methods define in it super class. Subclasses generally add new methods and properties specific to that class. Sub classes may refine are constraint the state and behavior inherited from its super class . In our example race car only one occupant the driver. In this manner sub classes modify the attribute of tit super classes, car. Motor Vehicle Bus Truck Car Fig: Super class / sub Class The Car class in a formal class also called an abstract class. Formal or abstract classes have no instance but define the common behaviors that can be inherited by more specific classes. In some object oriented language the terms super class and sub class are used to instead of base and derive. Inheritance Inheritance is a property of object oriented system that allows objects to be build form other object. Inheritance allows explicitly taking advantage of the commonality of a object when constructing new classes. Inheritance is relationship between classes where one class is the parent class of another class. The parent class is known as the base class or super class. For example, The car class defines the general behavior of class. The Ford class inherits the general behavior form the car class and adds behavior specific to Fords. Dynamic inheritance allows object to change and evolve other time. Since base classes provide properties and attributes for on object, changing base classes changes the property an attributes of class. Vehicle Car Ford Taurus Mustang Thunderbird Fig: Class Hierarchy Multiple inheritance Some object oriented system permit a class to inherit its state and behavior from more than one super class. This kind of inheritance referred to as multiple inheritance. For example a utility vehicle inherits attribute from both the car and Truck classes. Multiple inheritance can pose some difficulties. For example several distinct parent classes can declare a member within a multiple inheritance hierarchy. This then can become an issue of choice particularly an several super classes define a same method. It also a more difficult to understand programs written in multiple inheritance system. The benefits of multiple inheritance in the language with single inheritance Is to inherit form the most appropriate class and then add an object of the class as an attribute. (ii). Object relationships and associations (8) OBJECT RELATIONSHIPS AND ASSOCIATIONS Association represents the relationship between object and classes. Fort example, in the statement “A pilot can fly planes”. Here can is association. Associations are bi directional that means they can be transferred in both directions, perhaps with different call notations. The direction implied by the name is the forward direction. The opposite direction is the inverse direction. Pilot Can fly Flown by Plane An important issue in association is cardinality, which specifies how many instance of one class nay relate to single instances of an associated class. Cardinality constraints the number of related objects and often is described as being “one or many” Consumer Producer Association A special form of association is a consumer producer relationship, also known as a client server association are a use relationship. The consumer producer relationship can be viewed as one way interaction: One object requires a service of another object. The object that makes the request is the consumer or client, and the object that receives the request and provides the service is the producer or server. 3. Briefly explain about the characteristics of an object and software development processes? Characteristics of an object Objects in "object-oriented programming" are essentially data structures together with their associated processing routines. For instance, a file is an object: a collection of data and the associated read and write routines. Objects are considered instances of classes. 1. An object has identity (it acts as a single whole). 2. An object has state (it has various properties, which might change). 3. An object has behavior (it can do things and can have things done to it). Characteristics of OOP are: Class definitions – Basic building blocks OOP and a single entity which has data and operations on data together 5. Objects – The instances of a class which are used in real functionality – its variables and operations 6. Abstraction – Specifying what to do but not how to do ; a flexible feature for having a overall view of an object’s functionality. 4. Encapsulation – Binding data and operations of data together in a single unit – A class adhere this feature 8. Inheritance and class hierarchy – Reusability and extension of existing classes 9. Polymorphism – Multiple definitions for a single name - functions with same name with different functionality; saves time in investing many function names Operator and Function overloading 10. Generic classes – Class definitions for unspecified data. They are known as container classes. They are flexible and reusable. 7. Software Process The process that deals with the technical and management issues of software development is called a software process. A software development project must have at least development activities and project management activities. The fundamental objectives of a process are the same as that of software engineering viz. optimality and scalability. Optimality means that the process should be able to produce high-quality software at low cost, and scalability means that it should also be applicable for large software projects. To achieve these objectives, a process should have some properties. Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed. Predictability can be considered a fundamental property of any process, In fact, if a process is not predictable, it is of limited use. One of the important objectives of the development project should be to produce software that is easy to maintain. And the process should be such that it ensures this maintainability. Testing consumes the most resources during development. Underestimating the testing effort often causes the planners to allocate insufficient resources for testing, which, in turn, results in unreliable software or schedule slippage. The goal of the process should not be to reduce the effort of design and coding, but to reduce the cost of maintenance. Both testing and maintenance depend heavily on the design and coding of software, and these costs can be considerably reduced if the software is designed and coded to make testing and maintenance easier. Hence, during the early phases of the development process the prime issues should be "can it be easily tested" and "can it be easily modified". Errors can occur at any stage during development. However error detection and correction should be a continuous process that is done throughout software development. Detecting errors soon after they have been introduced is clearly an objective that should be supported by the process. A process is also not a static entity. As the productivity (and hence the cost of a project) and quality are determined largely by the process to satisfy the engineering objectives of quality improvement and cost reduction, the software process must be improved. Having process improvement as a basic goal of the software process implies that the software process used is such that is supports its improvement. 4. Explain about object oriented system development methodology. Object-oriented development offers a different model from the traditional software development approach, which is based on functions and procedures. In simplified terms, object-oriented system development is a way to develop software by building self-contained modules or objects that can be easily replaced, modified, and reused. Furthermore, it encourages a view of the world as a system of cooperative and collaborating objects. In an object-oriented environment, software is a collection of discrete objects that encapsulate their data as well as the functionality to model real-world “objects.” An object orientation yields important benefits to the practice of software construction. Each object has attributes (data) and methods (functions). Objects are grouped into classes; in object- oriented terms, we discover and describe the classes involved in the problem domain. In an object-oriented system, everything is an object and each object is responsible for itself. For example, every Windows application needs windows objects that can open themselves on screen and either display something or accept input. A windows object is responsible for things like opening, sizing, and closing itself. Frequently, when a window displays something, that something also is an object (a chart, for example). A chart object is responsible for things like maintaining its data and labels and even for drawing itself. The object-oriented environment emphasizes its cooperative philosophy by allocating tasks among the objects of the applications. In other words, rather than writing a lot of code to do all the things that have to be done, you tend to create a lot of helpers that take on an active role, a spirit, and that form a community whose interactions become the application. Instead of saying, “system”, compute the payroll of this employee,” you tell the employee object, “compute your payroll.” This has a powerful effect on the way we approach software development. UNIT II PART A 1. What is the need of an Object diagram? An object diagram is used to show the existence of objects and their relationships in the logical design of a system. A static object diagram is an instance of a class diagram. It shows snapshot of the detailed state of the system at a point in time. 2. Write some applications of object model? They include Air traffic control Animation Avionics Database Robotics etc. 3. Name the five levels of process maturity in OOD? Initial Repeatable Defined Managed and Optimized 4. What are the steps followed in macro development process? Conceptualization Analysis and development of the model Design or create the system architecture Evolution or implementation Maintenance. 5. Give short notes on OMT functional model. OMT functional model uses dataflow diagram that shows the flow of data between different processes in a business.Data flow diagrams use four primary symbols. They are process, data flow, data store, external entity. 6. What is Objectory? Name the models in objectory. Objectory, is a method or object-oriented development with the specific aim to fit the development of large, real-time systems. Model in objector are Use case model, domain object model, analysis object model, implementation model, test model. 7. What is Inception? Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement, creation of a business case, and preparation of the development environment. 8. Define Domain model. Write any two advantages of modeling? A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’ that exist or events that transpire in the business environment. Advantages: The main reason for modeling is the reduction of complexity. The cost of the modeling analysis is much lower than the cost of similar experimentation conducted with real time. 9. Define Dynamic model? It can be viewed as a collection of procedures or behaviors that taken together reflect the behavior of a system over time. Dynamic modeling is the most useful during the design and implementation phases of the system development. 10.What is a qualifier? Give one example. A qualifier is an association attribute. The qualifier rectangle is part of the association path, not part of the class. For example, a person object may associate bank object. An attribute of this association is the account#. The account# is the qualifier of this association. PART B 1.What are the various diagrams that are used in analysis and design steps Of Booch Methodology? Explain with your own example. The Booch methodology covers the analysis and design phases of systems development. Booch sometimes is criticized for his large set of symbols. The Booch method consists of the following diagrams: Class diagrams Object diagrams State transition diagrams Module diagrams Process diagrams Interaction diagrams Class Diagram Class Diagram A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. Object diagram is instance of a class diagram. A central modeling technique that runs through nearly all object-oriented methods. A class diagram shows the existence of classes and their relationships in the logical view of a system Interaction Diagram Interaction diagrams describe how groups of objects collaborate to get the job done. Interaction diagrams capture the behavior of a single use case, showing the pattern of interaction among objects. The purpose of Interaction diagrams is to: Model interactions between objects Assist in understanding how a system (a use case) actually works Verify that a use case description can be supported by the existing classes. Identify responsibilities/operations and assign them to classes There are two kinds of Interaction diagrams: Sequence diagrams Collaboration diagrams State Transition Diagram A state diagram is a type of diagram used in UML, it describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. Many forms of state diagrams exist, which differ slightly and have different semantics. Booch's work on object-oriented design is well matured and respected in the field of object- oriented analysis and design. Object-Oriented design with applications is an ideal text for introducing the concepts of object-orientation. It is divided into three main sections, the first introducing key object-oriented concepts, the second setting out Booch's method for object- oriented design and the third giving five case studies. Booch suggests the following steps for analyzing a system in preparation for designing a solution in an object-oriented manner: 1. Define the problem. 2. Develop an informal strategy for the software realization of the real world problem domain. 3. Formalize the strategy. The problem is defined in a concise, informal textual description, then information on the objects and operations represented in the system can be obtained from this description. Objects are represented by nouns, and operations by verbs. Pressman [Pres87] notes that the first two steps are actually performed during the software requirements analysis stage of development, rather than the design. Booch suggests the following order of events for the formalization of the strategy: Identify the classes and objects at a given level of abstraction. Identify the semantics of these classes and objects. Identify the relationships among these classes and objects. Implement these classes and objects. The process of object-oriented design starts with the discovery of the classes and objects that form the vocabulary of our problem domain; It stops whenever we find that there are no new primitive abstractions and mechanisms or when the classes and objects we have already discovered may be implemented by composing them from existing reusable software components. Implementing classes and objects involves delving into the classes and objects and determining how to implement them in the chosen programming language. This is also the step where components are used, and the classes and objects are structured into modules. The notations for class and object modeling use annotations or variant symbols (e.g. different kinds of arrow) to convey detailed information. Booch suggests that a subset of the notations can be used in the earlier stages of design, with the detail being filled in later. There is also a textual form for each notation, consisting of templates for documenting each major construct. The notations are defined in terms of a large repertoire of symbols, but there seems to be no real definition of syntax or static semantics. 2. Briefly explain about Rumbaugh methodology RUMBAUGH ET AL.’S OBJECT MODELING TECHNIQUE: The object modeling technique (OMT) presented by Jim Rumbaugh. It describes a method for analysis, design, and implementation of a system using an objectoriented technique. OMT is a fast, intuitive approach for identifying and modeling all the objects making up a system. Details such as class, attributes, method, inheritance, and association also can be expressed easily. The dynamic behavior of objects within a system can be described using the OMT dynamic model. This model lets you specify detailed state transitions and their descriptions within a system. Finally, a process description and consumer-producer relationships can be expressed using OMT’s functional model.OMT consists of four phases, which, which can be performed iteratively: 1. Analysis: The results are objects and dynamic and functional models. 2. System design: The results are a structure of the basic architecture of the system along with high-level strategy decisions. 3. Object design: This phase produces a design document, consisting of detailed objects static, dynamic, and functional models. 4. Implementation: This activity produces reusable, extendible, and robust code. OMT separates modeling into three different parts: 1. An object model, presented by the object model and the data dictionary. 2. A dynamic model, presented by the state diagrams and event flow diagrams. 3. A functional model, presented by data flow and constraints. The Object Model: The object model describes the structure of the objects in the system: their identity, relationships to other objects, attributes, and operations. The object model is represented graphically with an object diagram. The object diagram contains classes interconnected by association lines. Each class represents a set of individual objects. Client Account First name Last name PinCode Checking account withdraw Transaction Clinet account Number Balance Acc transaction Transdate Transtime Transtype Amount postbal Deposit Withdraw Create Transccation CheckingSavinAccount Saving account Fig: Object Model The association lines establish relationships among the classes. Each association line represents a set of links from the objects of one class to the objects of another class. The OMT Dynamic Model: OMT provides a detailed and comprehensive dynamic model, in addition to letting you depict states, transitions, events, and actions. The OMT state transition diagram is a network of states and events. Each state receives one or more events, at which time it makes the transition to the next state. The next state depends on the current state as well as the events. The OMT Functional Model: The OMT data flow diagrams (DFD) shows the flow of data between different processes in a business. An OMT DFD provides a simple and intuitive method for describing business processes without focusing on the details of computer systems. Data flow diagrams use four primary symbols: 1. The Process is any function being performed; for example, Verify Password or PIN in the ATM system. 2. The Data flow shows the direction of data element movement; for example, PIN code. 3. The data store is a location where data are stored; for example, account is a data store in the ATM example. 4. An external entity is a source or destination of a data element; for example, the ATM card reader. Overall, the Rumbaugh OMT methodology provides one of the strongest tool sets for the analysis and design of object-oriented systems. 3. Explain about Booch methodology The booch methodology is a widely used object oriented method that helps you to design your system using object paradigm. This methodology covers the analysis and design phases of systems development. Booch sometimes is criticized for his large set of symbols. The Booch method consists of the following diagrams: o Class diagrams Object diagrams o State transition diagrams o Module diagrams o Process diagrams o Interaction diagrams The Booch methodology prescribes – A macro development process – A micro development process. The Macro Development Process: It servers as a controlling framework for the micro process. The primary concern is Technical Management of the System. The macro development process consists of the following steps: 1. 2. 3. 4. 5. Conceptualization Analysis and development of the model. Design or create the system architecture. Evolution or implementation. Maintenance. 1.Conceptualization: • • Establish the core requirements of the system Establish a set of goals and develop prototype to prove the concept 2.Analysis and development of the modal: • Using the class diagram to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system. • Using the object diagram to describe the desired behavior of the system in terms of scenarios or, alternatively • Using the interaction diagram to describe behavior of the system in terms of scenarios 3.Design or create the system architecture: • Using the class diagram to decide what mechanisms are used to regulate how objects collaborate • Using the module diagram to map out were each class and object should be declared • Using the process diagram to determine to which processor to allocate a process. Also, determine the schedules for multiple processes on each relevant processor 4.Evolution or implementation: • Successively refine the system through many iterations • Produce a stream of software implementations, each of which is refinement of the prior one 5.Maintenance: • Make localized changes to the system to add new requirements and eliminate bugs. Car color manufacture rsuperclass cost inherits Ford inherits Es co rt Mustang Taurus The Micro Development Process Each micro development process has its own micro development process.The micro development process consists of the following steps: • • • • Identify classes and objects. Identify class and object semantics. Identify class and object relationships. Identify class and object interfaces and implementation Operator::TurnOffAlarm Enabled SoundAlarm Silenced Sounding SilenceAlarm Enable Disable AlarmFixed Disabled 4. Briefly explain about UML Dynamic Modeling. Unified Modeling Language A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it. Most of the modeling techniques involve graphical languages. Objectory is build around several different models Use-case model : The use-case model defines the outside and inside of the system’s behavior. Domain object model: Objects of the real world are mapped into the domain object model. Analysis object model: The analysis object model presents how the source code should be carried out and written. Implementation model The implementation model represents the implementation of the system. Test model: The test model constitutes the test plan, specification and reports. Static or Dynamic Models Static Model Static model can be viewed as a snapshot of a system’s parameter at rest or at a specific point in time. Static model are needed to represent to represent the structural or static aspect of a system. Dynamic Model A dynamic model can be viewed as a collection of procedures or behaviors that reflect the behavior of a system over time. Dynamic relationship show how the business objects interact to perform task. Advantages of Modeling Models reduce complexity by separating those aspects that are unimportant from those that are important. Models enhance learning. The cost of the modeling analysis is much lower than the cost of similar experimentation conducted with a real system. Manipulation of the model (changing variables) is much easier than manipulating a real system. The goals of UML were as follows 1. Provide user a ready to use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanism to extend the core concepts. 3. Be independent of particular programming language and development process. 4. Provide a formal basis for understanding the modeling language. 5. Support higher level development concept. 6. Integrate best practice and methodologies. UML Diagrams The UML defines nine graphical diagrams: 1. Class diagram 2. Use-case diagram 3. Behavior diagram 3.1 Interaction diagram 3.1.1 Sequence diagram 3.1.2 Collaboration diagram 3.2 State chart diagram 3.3 Activity diagram 4. Implementation diagram 4.1 Component diagram 4.2 Deployment diagram UML Class diagram A class diagram is a collection of static modeling elements, such as classes and their relationship , connected to graph to each other and to their contents. Account Number Balance Deposit Withdraw Create Transccation Class notation: static structure A class is rectangle with three components separated by horizontal lines. The top name compartment holds the class name, other general properties of the class such as attributes are in the middle compartment and the bottom holds the list of methods. Object diagram A static object diagram is an instance of a class diagram. It was snapshot of the detailed state of the system at a point in time. Notation is same for an object diagram and class diagram. Association Role A simple association , a solid line connecting two class symbols. The end of an association where it connects to a class, shows the association role. The role is part of an association Qualifier A qualifier is an association attribute. For example, a person object may be associated to a bank object. Multiplicity Multiplicity specifies the range of allowable associated classes. It given for roles with in association, parts within composition, repetition and other purposes. Use Case Diagram A use case diagram is a graph of actor, a set of use cases enclosed by a system boundary, communication association between the actor and the usecase and generalization among the use cases. Make a call Take the call Operator Do research Return a call Spplier The following relationship are used in use- case diagram Communication - The communication relationship of an actor in a use case is shown by connecting the actor symbol to the use – case symbol with a solid path. Uses - A uses relationship between use cases is shown by a generalization arrow from the use case. Extends – The extend relationship is used one use case that is similar to another use case but does it bit more. Interaction Diagrams UML provides two sorts of interaction diagram, • • sequence and collaboration diagrams. Collectively, the objects which interact to perform some task, together with the links between them, are known as a collaboration • • • Objects o Each object is shown as rectangle, which is labelledobjectName: className Links o Links between objects are shown like associations in the class model. Actors o Actors can be shown as on a use case diagram Diagram Page No: 104 & 105 State Chart Diagram A state chart diagram (also called a state diagram) shows the sequence of states that an object goes through during its life in response to outside stimuli and messages. A state chart diagram is a view of a state machine that models the changing behavior of a state. State chart diagrams show the various states that an object goes through, as well as the events that cause a transition from one state to another. Diagram model elements The common model elements that state chart diagrams contain are: States Start and end states Transitions Entry, do, and exit actions A state represents a condition during the life of an object during which it satisfies some condition or waits for some event. Start and end states represent the beginning or ending of a process. A state transition is a relationship between two states that indicates when an object can move the focus of control on to another state once certain conditions are met. Activity Diagram • Activity Diagram – a special kind of State chart diagram, but showing the flow from activity to activity (not from state to state). • Activity – an ongoing non-atomic execution within a state machine. Activities ultimately result in some action. – A real world process or execution of a software routine • Action – made up of executable atomic computations that results in a change in state of the system or the return of a value (i.e., calling another operation, sending a signal, creating or destroying an object, or some pure computation). Activity diagrams commonly contain: • • Activity states and action states Transitions Implementation diagrams Implementation diagram show the implementation phase of systems development such as source code structure and runtime implementation structure. Two types of implementation diagram: Component diagram: it shows the structure of code it self. Deployment diagram: shows the structure of runtime system. Component Diagram: Component diagrams model the physical component in a design. This high level components may or may not be equivalent to many smaller components in the application. Another way of looking at components is the concept of packages. A package is used to show how you can group classes together. Deployment Diagram: This shows the configuration of run-time processing elements and software components, process and objects that live in them. It is a graph of nodes connected by communication association, nodes may contain component, instances, which means that the component lives or runs on that node. Components are connected by other components by dashed arrow dependencies, usually through interfaces. (FOR DIAGRAM REFER PGNO:113 in textbook) 5. Briefly explain about design patterns and frameworks. A pattern is an instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces. The main idea behind using patterns is to provide documentation to help categorize and communicate about solutions to recurring problems. The pattern has a name to facilitate discussion and the information it represents. A good pattern will do the following: It solves a problem. Patterns capture solutions, not just abstract principles or strategies. It is a proven concept. Patterns capture solutions with a track record, not theories or speculation. The solution is not obvious. The best patterns generate a solution to a problem indirectly—a necessary approach for the most difficult problems of design It describes a relationship. Patterns do not just describe modules, but describe deeper system structures and mechanisms. The pattern has a significant human component. All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility. Framework A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a development. A single framework typically encompasses several design patterns and can be viewed as the implementation of a system of design patterns. Differences Between Design Patterns and Frameworks Design patterns are more abstract than frameworks. Frameworks can be embodied in the code, but only example of pattern can be embodied in code. A strength of framework can be written in programming language. Design patterns are smaller architectural elements than frameworks. A typical framework contain several design pattern but the reverse is never true. Design patterns are less specialized than frameworks. Framework always have a particular application domain. The design pattern can be used in nearly any kind of application . 6. Briefly explain about unified approach. The unified approach to software development has the following processes and concepts. The processes are: Use-case driven development Object oriented analysis Object oriented design Incremental development and prototyping Continuous testing The method and technology include Unified modeling language used for modeling Layered approach Repository of object oriented system development pattern Component based development Object oriented Analysis Analysis is the process of extracting the need and what the system must to do satisfy the users requirements. The goal of object oriented analysis is to first understand the domain of the problem and the system responsibility by understanding how the user use the system. OOA process consists of the following steps 1. Identify the actors 2. Develop a simple business process model using UML activity diagram 3. Develop the use case 4. Develop interaction diagram 5. Identify classes Object oriented Design OOD process consists of; Designing classes, their attributes, methods, association, structure and protocols , apply design axioms Design the access layer Design and prototype user interface. User satisfaction and usability test based on the usage / use case Iterate and refine the design Iterative development and continuous Testing Since testing uncovers the design weaknesses or provide additional information repeat the entire processes. The UA encourages the integration of testing plans from day 1 of the project. Usage scenarios or Use Cases can become test scenarios; therefore, use cases will drive the usability testing. Modeling based on the Unified modeling Language The UML becoming universal language for modeling system. It is used to express model of many different kind and purposes. The UA uses the unified modeling language (UML) to describe and model the analysis and design phases of system development. The UA proposed Repository The requirement, analysis, design, and implementation documents should be stored in the repository, so reports can be run on them for traceability. This allows us to produce designs that are traceable across requirements, analysis, design, implementation, and testing. The layered approach to software development Most systems developed with today's CASE tools or client-server application development environments tend to lean toward what is known as two-layered architecture: interface and data. The better approach to system architecture is one that isolates the functions of the interface from the function of the business. This approach also isolates the business form the details of the data access. The business Layer The business layer contains all the objects that represents the business. Model the object of the business and how they interact to accomplish the business processes. These object should not responsible for the following. Displaying details: Business object should have no special knowledge of how they are being displayed and by whom. They are designed to be independent of any particular interface, so the details of how to display an object should exist in the interface layer of the displaying it. Data access details: Business object also should have no special knowledge of where they come from. It does not matter to the business model whether the data are stored and retrieved via SQL. The User Interface Layer The user interface layer consists of objects with which user interacts as well as objects needed to manage or control the interface. The user interface layer also called view layer. It responsible for two major aspects. Responding to user interaction: The user interface layer object must be designed to translate action by the user such as clicking on a button or selecting from a menu in to an appropriate response. Displaying business object: This layer must paint the picture of business object for the user. The Access Layer The access layer contains objects that know how to communicate with the place where the data actually reside whether it be relational database, main frame, internet or file. The layer has two major two responsibilities: Translate request: The access layer must be able to translate any data related request from the business layer into the appropriate protocol for data access. Translate results: The access layer also must be able to translate the data retrieved back into the appropriate business object and pass those object backup into the business layer. Access objects are identified during object oriented design.
© Copyright 2024