The book Object-Oriented Analysis and Design Through Unified Modeling Language adheres to the B.Tech. and MCA syllabus of JNT University, Hyderabad and many other Indian universities. This book contains twenty chapters. The first two chapters represent the fundamentals of Object Technology, OOP and OOAD and how we are inclined towards Object-Oriented Analysis and Design starting from traditional approach and the different approaches suggested by the three pioneers-Booch, Rum Baugh and Jacobson. Chapters 3 to 18 represent the UML language, the building blocks of UML i.e., things, relationships and diagrams and the use of each diagram with an example. Chapters 19 and 20 discuss a case study "Library Management System". In this case study one can get a very clear idea what object oriented analysis and design is and how UML is to be used for that purpose. Appendix-A discusses the different syntactic notations of UML and Appendix-B discusses how the three approaches of Booch, Rum Baugh and Jacobson are unified and about the Unified Process.
Additional Info
  • Publisher: Laxmi Publications
  • Language: English
  • ISBN : 978-93-80386-54-6
  • Chapter 1

    INTRODUCTION TO OBJECT TECHNOLOGY Price 2.99  |  2.99 Rewards Points

    The traditional focus of computer systems had been on the hardware. Since the early 1950s, computer hardware was quite expensive. At the same time, there were no desktops or personal computers. All computer processing was based on large mainframe or mini computers, which were very expensive and difficult to maintain. However, this pattern started changing towards the 1980s with the introduction of the personal computer. It has changed so dramatically from that point onwards that in the last few years, almost all concerns regarding the hardware have been nullified, and the chief concern of all the concerned parties in a software project is the software itself.
  • Chapter 2

    OOP AND OOAD Price 2.99  |  2.99 Rewards Points

    In the earlier sections we have defined that an object is a self-sufficient entity. While thinking in terms of the computing world we can also define that “an object is a basic run time entity”. Programming problem is analyzed in terms of objects and the nature of communication between them. Program objects should be chosen such that they match closely with the real world objects. Objects occupy space in memory and have an associated address like a record in Pascal, or a structure in C.
  • Chapter 3

    MODELING Price 2.99  |  2.99 Rewards Points

    The concept of modeling is quite old. We use models in almost everything that we do. Let us consider a few simple examples.
  • Chapter 4

    AN OVERVIEW OF UML Price 2.99  |  2.99 Rewards Points

    THE UML Any natural language like English provides a vocabulary and the rules for combining words in that vocabulary for the purpose of communication. A modeling language like UML is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. Software intensive systems require a language that addresses the different views of a system’s architecture. The vocabulary and rules of a language such as UML tells you how to create wellformed models, but they do not tell you what models you should create and when you should create. A well-defined process will guide you in deciding what artifacts to produce, what activities and what workers to use to create them and manage them, and how to use those artifacts to measure and control the project as a whole.
  • Chapter 5

    CLASSES AND RELATIONSHIPS Price 2.99  |  2.99 Rewards Points

    class is a description of a set of objects that share the same attributes, operations, relationships and semantics. Graphically a class is rendered as a rectangle having three components— for name, attribute and operations.
  • Chapter 6

    COMMON MECHANISMS AND DIAGRAMS Price 2.99  |  2.99 Rewards Points

    COMMON MECHANISMS AND DIAGRAMS
  • Chapter 7

    ADVANCED CLASSES AND ADVANCED RELATIONSHIPS Price 2.99  |  2.99 Rewards Points

    The UML provides some advanced properties to be attached to classes to represent a class in more detail. We can call these classes as advanced classes, as it permits you to visualize, specify, construct, and document a class to any level of detail you wish.
  • Chapter 8

    INTERFACES,TYPES,ROLES AND PACKAGES Price 2.99  |  2.99 Rewards Points

    Graphically an interface is represented by a circle and in its expanded form it may be represented as a stereotyped class. Interface can be named by a simple name or path name. In path name the interface is prefixed by the package name in which the interface lives. Fig. 8.1 represents the simple and path naming. IUnknown and ISpell are the simple names. In the path name Networking::IRouter, IRouter is the interface name and Networking is the package inside which IRouter lives. Fig. 8.2 represents the expanded form represented as a stereotyped class.
  • Chapter 9

    CLASS DIAGRAM AND OBJECT DIAGRAM Price 2.99  |  2.99 Rewards Points

    A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships. Graphically a class diagram is a collection of vertices and arcs. A class diagram shares the common properties like other diagrams. It is distinguished from other diagrams by it’s content. Class diagrams commonly contain the following things: • Classes • Interfaces • Collaborations • Dependency, generalization and association relationships. • Like other diagrams, class diagrams may contain notes and constraints. Class diagrams may also contain packages or subsystems both of which are used to group elements of your model to larger chunks.
  • Chapter 10

    INTERACTION AND INTERACTION DIAGRAM Price 2.99  |  2.99 Rewards Points

    An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is a specification of a communication between objects that conveys information transfer. You may find an interaction wherever objects are linked to one another. You will find interactions in the collaboration of objects that exist in the context of your system or subsystem. You will also find interactions in the context of an operation. You will find interactions in the context of a class. Most often you will find interactions in the collaboration of objects that exist in the context of your system or subsystem as a whole. You will also find interactions among objects in the implementation of an operation. You can use interactions to visualize, specify, construct, and document the semantics of a class.
  • Chapter 11

    USE CASE AND USE CASE DIAGRAM Price 2.99  |  2.99 Rewards Points

    use case is a set of sequences of actions that performs an observable result to an actor. Graphically a use case is represented by an ellipse. Every use case must have a name that distinguishes it from other use cases. The name can be simple name or path name. In path name the use case name must be prefixed by the name of the package in which that use case lives. For example in ATM system, withdraw is a use case.
  • Chapter 12

    ACTIVITY DIAGRAM Price 2.99  |  2.99 Rewards Points

    An activity diagram shows the flow from activity to activity. An activity is a non-atomic execution. Activities when executed, results in some action, which is made up of executable atomic computations that result in a change in state of the system or the return of a value. Actions encompass calling another operation, sending a signal, creating or destroying an object, or some pure computation.
  • Chapter 13

    EVENTS AND SIGNALS Price 2.99  |  2.99 Rewards Points

    An event is the specification of a significant occurrence that has a location in time and space. In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition. Events may be external or internal. External events are those that pass between the system and its actors. For example, the pushing of a button. Internal events are those that pass among the objects that live inside the system. An overflow exception is an example of an internal event.
  • Chapter 14

    STATE MACHINE Price 2.99  |  2.99 Rewards Points

    A state machine is a behavioral diagram that specifies the sequences of states an object goes through during its lifetime in response to events, together with it's responses to those events. A state is a situation in the life of an object during which it satisfies some condition, performs some activity, or waits for some event to occur. A state is represented by a rectangle with curved corners. For example ATM system can have three states—Idle , Active and Maintenance.
  • Chapter 15

    TIME AND SPACE Price 2.99  |  2.99 Rewards Points

    In the real world an event may happen at a predictable or unpredictable time and location. For example, while coming to college at 8.30 a.m. I saw an accident took place when a car collided to a bus near the traffic junction. This event is having two main elements : time (i.e., 8.30 a.m.) and location (i.e., traffic junction). Similarly in our software systems also events occurring have a time and space (location). Modeling this time and space is an essential feature of any system. This time and space can be represented in different forms.
  • Chapter 16

    STATE CHART DIAGRAM Price 2.99  |  2.99 Rewards Points

    activity diagram is a special case of a state chart diagram in which all or most of the states are activity states and all or most of the transitions are triggered by completion of activities in the source state. Thus, both activity and state chart diagrams are useful in modeling the lifetime of an object. However an activity diagram shows flow of control from activity to activity, a state chart diagram shows flow of control from state to state.
  • Chapter 17

    COMPONENT AND COMPONENT DIAGRAM Price 2.99  |  2.99 Rewards Points

    COMPONENT AND COMPONENT DIAGRAM
  • Chapter 18

    DEPLOYMENT AND DEPLOYMENT DIAGRAM Price 2.99  |  2.99 Rewards Points

    A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube. Every node must have a name that distinguishes it from other nodes. A node name may be a text consisting of any number of letters, numbers, and certain punctuation marks (except marks like colon) and may continue over several lines. In practice node names are short nouns drawn from the vocabulary of the implementation.
  • Chapter 19

    OBJECT ORIENTED ANALYSIS Price 2.99  |  2.99 Rewards Points

    OBJECT ORIENTED ANALYSIS
  • Chapter 20

    OBJECT ORIENTED DESIGN Price 2.99  |  2.99 Rewards Points

    Many times, it is tricky to make a clear distinction between object-oriented analysis and object-oriented design. In short, object oriented analysis involves the step of classification. In other words, a problem is analyzed so that many classes of objects can solve it. Analysis involves determining the relationship between objects and their behavior. Object-oriented design helps a software engineer to identify the objects belonging to each class and how they are interrelated. Additionally, the design phase also specifies the relationships between objects, how the behavior would be implemented, and how objects communicate with each other.

About the Author

Not available