Note for UML and Design Pattern - UDP by shaik shabeer

Topics ( 4 )

Text from page-1

UML & DESIGN PATTERNS (R13) UNIT-I 1.1 What is Analysis and Design? Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new online trading system is desired, how will it be used? What are its functions? Design emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. 1.2 What is Object-Oriented Analysis and Design? Definition: OOAD is a technical method of analyzing and designing an application based on that system’s object models (the logical components of the system that interact with one another). During object-oriented analysis there is an emphasis on finding and describing the objects — or concepts—in the problem domain. For example, in the case of the flight information system, some of the concepts include Plane, Flight, and Pilot. During object-oriented design there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a Plane software object a getFlightHistory method (see below fig.) may have a tailNumber attribute and Fig. Object-orientation emphasizes representation of objects. Finally, during implementation or object-oriented programming, design objects are implemented, such as a Plane class in Java. Advantages Ch. Vijayananda Ratnam @Dept. of CSE 1

Text from page-2

UML & DESIGN PATTERNS (R13)   Encourages Encapsulation: Easy to Understand Disadvantages  Not suited to Procedural Applications  Too Complex for Simple Applications An Example of Object – Oriented Analysis and Design: “A Dice Game” The dice game is very simple problem, presented in order to focus on some of the steps and artifacts in object – oriented analysis and design rather than on the problem domain. A "dice game" in which a player rolls two dice. If the total is seven, they win; otherwise, they lose. Most essential and commonly used steps in OOAD: 1. Define Use Cases Requirements analysis may include stories or scenarios of how people use the application; these can be written as use cases. They are a popular tool in requirements analysis. For example, here is a brief version of the Play a Dice Game use case: Play a Dice Game: Player requests to roll the dice. System presents results: If the dice face value totals seven, player wins; otherwise, player loses. Use case diagram 2. Define a Domain Model A decomposition of the problem domain involves an identification of    Concepts Attributes Associations in the domain that are considered important. A domain model is a visualization of the concepts of a real-world domain. Thus, it has also been called a conceptual object model. Ch. Vijayananda Ratnam @Dept. of CSE 2

Text from page-3

UML & DESIGN PATTERNS (R13) The result can be expressed in a conceptual model, which is illustrated in a set of diagrams that depict concepts (objects). For example, a partial domain model is shown in fig. Fig. Partial domain model of the dice game. This model illustrates the concepts Player, Die, and DiceGame, with their associations and attributes. 3. Assign Object Responsibilities and Draw Interaction Diagrams Object - oriented design is concerned with defining logical software specifications that fulfill the functional requirements based on decomposition by classes of objects. An essential step in this phase is the allocation of responsibilities to objects and illustration how they interact via messages, expressed in collaboration diagrams. Collaboration diagrams show the flow of messages between instances and the invocation of methods For example, the sequence diagram which shows the flow of messages between software objects in Fig. illustrates an OO software design, by sending messages to instances of the DiceGame and Die classes. Note this illustrates a common real-world way the UML is applied: by sketching on a whiteboard. Fig. Sequence diagram illustrating messages between software objects. Ch. Vijayananda Ratnam @Dept. of CSE 3

Text from page-4

UML & DESIGN PATTERNS (R13) The collaboration diagram in Figure illustrates the essential step of playing by sending messages to instances of the Player and die classes. Fig. Collaboration diagram illustrating messages between software objects. 4. Define Design Class Diagrams “These illustrate class definitions that are to be implemented in software” In order to define a class, several questions must be answered   How do objects connect to other objects? What are the methods of a class? To answer these questions,For example, in the dice game, an inspection of the sequence diagram leads to the partial design class diagram shown in Fig. Since a play message is sent to a DiceGame object, the DiceGame class requires a play method, while class Dierequires roll and getFaceValue method. Fig. Partial design class diagram. 1.3 Iterative and Evolutionary Development In this approach, development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations. The outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities. The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. Ch. Vijayananda Ratnam @Dept. of CSE 4