Spring 2012 Master of Computer Application (MCA) Semester V MC0083 OOAD Using UML 4 Credits (Book ID: B0969)

9) Assignment Set 2

1. Describe the following: o Two orthogonal views of the software o Advantages of Object Orientation Answer:
(A)Two orthogonal views of the software Niklaus Wirth, the inventor of Pascal says: Algorithms + Data structures = Programs A software system is a set of mechanisms for performing certain action on certain data. Traditional development techniques focus on the functions of the system. Object oriented systems development centers on object, which combines data and functionality. (B) Advantages of Object Orientation Object oriented systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater design and code reuse. 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 (attributes) and functions (methods), they work at a higher level of abstraction. 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. 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. Promotion of reusability: Objects are reusable because they are modeled directly out of realworld 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.

2. Describe the following Object Oriented concepts with relevant real-time examples: o Class hierarchy & Inheritance o Aggregation and object containment o Static and dynamic binding Answer: (A) Class hierarchy & Inheritance
Class hierarchy An object-oriented system organizes classes into a subclass-superclass hierarchy. Different properties and behaviors are used as the basis for making distinctions between classes and subclasses. At the top of the class hierarchy, are the most general classes and at the bottom, are the most specific. A subclass inherits all the properties and methods (procedures) defined in its superclass. Subclasses generally add new methods and properties specific to that class. Subclasses may refine or constrain the state and behavior inherited from its superclass. An object-oriented system eliminates duplicated effort by allowing classes to share and reuse behaviors. Formal or abstract classes have no instances but define the common behaviors that can be inherited by more specific classes. Super and subclasses may also be called as base and derived classes.

Fig. 2.4: Superclass / subclass hierarchy

Fig. 2.5: Class hierarchy for Ford class

Inheritance
Inheritance is the property of object-oriented systems that allows objects to be built from other objects. Inheritance allows explicitly taking advantage of the commonality of objects when constructing new classes. Inheritance is a relationship between classes where one class is the parent class of another (derived) class. The parent class is also known as the base class or super class. Inheritance provides programming by extension as opposed to programming by reinvention. The real advantage of using this technique is that we can build on what we already have and, more important, reuse what we already have. Inheritance allows classes to share and reuse behaviors and attributes. Where the behavior of a class instance is defined in that classs methods, a class also inherits the behaviors and attributes of all of its superclasses. Dynamic inheritance allows objects to change and evolve over time. More specifically, dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes) at run time.

Fig. 2.6: Inheritance allows reusability

Multiple Inheritance
Some object-oriented systems permit a class to inherit its state (attributes) and behaviors from more than one superclass. This kind of inheritance is referred to as multiple inheritance.

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 when several superclasses define the same method. It is also more difficult to understand programs written in multiple inheritance systems. One way of achieving the benefits of multiple inheritance in a language with single inheritance is to inherit from the most appropriate class and then add an object of another class as an attribute.

Fig. 2.7: Utility vehicle inherits from both the Car and Truck classes

(B) Aggregation and object containment

Aggregations and object containment All objects, except the most basic ones, are composed of and may contain other objects. Breaking down objects into the objects from which they are composed is decomposition. This is possible because an objects attributes need not be simple data fields; attributes can have reference to other objects. Since each object has an identity, one object can refer to other objects. This is known as aggregation, where an attribute can be an object itself.

Fig. 2.10: A Car object is an aggregation of other objects such as engine, seat, and wheel objects

Structured Approach
The Structured Analysis/Structured Design (SA / SD) approach encourages the top-down design (also known as top-down decomposition or stepwise refinement), characterized by moving from a general statement about the process involved in solving a problem down toward more and more detailed statements about each specific task in the process.

The main problem with this traditional way of programming is the following: The introduction of new classes of data with different needs requires changing the main logic of the program. It also may require the addition of new code in many different areas of the application. The object-oriented approach Object-oriented systems development consists of Object-oriented analysis Object-oriented information modeling Object-oriented design Prototyping and implementation Testing, iteration and documentation The first task in object-oriented analysis is to find the class of objects that will compose the system. At the first level of analysis, we can look at the physical entities in the system. Coad and Yourdon have listed the following clues for finding the candidate classes and objects: Persons: What role does a person play in the system? For example, the customers, employees of whom the system needs to keep track. Places: These are physical locations, buildings, stores, sites or offices about which the system keeps information. Things or events: These are events, points in time that must be recorded. Next, we need to identify the hierarchical relation between superclasses and subclasses. Another task in object-oriented analysis is to identify the attributes (properties) and behaviors (methods) of objects.

Fig. 2.11: Class hierarchy for the payroll application

(C) Static and dynamic binding

Static and dynamic binding

The process of determining (dynamically) at run time which functions to invoke is termed as dynamic binding. Making this determination earlier, at compile time, is called static binding. Static binding optimizes the calls. Dynamic binding occurs when polymorphic calls are issued. Object persistence An object can persist beyond application session boundaries, during which the object is stored in a file or a database, in some file or database form. The object can be retrieved in another application session and will have the same state and relationship to other objects as at the time it was saved. The lifetime of an object can be explicitly terminated. After an object is deleted, its state is inaccessible and its persistent storage is reclaimed. Its identity, however, is never reused. Meta-classes In object-oriented system everything is an object including a class. Class belongs to a class called meta-class, or class of classes. Classes are instances of a meta-class. The meta-class is a class and therefore an instance of itself. Meta-classes are used by the compiler. Meta-classes handle messages to classes, such as constructors, new, and class variables.

3. Describe the Language Architecture and Language Formalism with respect to UML Architecture. Answer:
Language Architecture and Language Formalism Four-Layer Meta model Architecture: The UML meta model is defined as one of the layers of a four-layer meta modeling architecture. This architecture is a proven infrastructure for defining the precise semantics required by complex models. There are several other advantages associated with this approach. They are as follows: It refines semantic constructs by recursively applying them to successive meta layers. It provides an architectural basis for defining future UML meta model extensions. It furnishes an architectural basis for aligning the UML meta model with other standards based on a four-layer meta modeling architecture, in particular the OMG Meta-Object Facility (MOF). The generally accepted framework for meta modeling is based on an architecture with four layers namely: meta-meta model meta model model user objects The functions of these layers are summarized in the following table. Table 6-1 Four Layer Meta modeling Architecture

The meta-meta modeling layer forms the foundation for the meta modeling architecture. The primary responsibility of this layer is to define the language for specifying a meta model. A meta-meta model defines a model at a higher level of abstraction than a meta model, and is typically more compact than the meta model that it describes. A meta-meta model can define multiple meta models, and there can be multiple meta-metamodels associated with each meta model. While it is generally desirable that related metamodels and meta-metamodels share common design philosophies and constructs, this is not a strict rule. Each layer needs to maintain its own design integrity. Examples of meta-metaobjects in the meta-metamodeling layer are: MetaClass, MetaAttribute, and MetaOperation. A metamodel is an instance of a meta-metamodel. The primary responsibility of the metamodel layer is to define a language for specifying models. Metamodels are typically more elaborate than the meta-metamodels that describe them, especially when they define dynamic semantics. Examples of metaobjects in the metamodeling layer are: Class, Attribute, Operation, and Component. A model is an instance of a metamodel. The primary responsibility of the model layer is to define a language that describes an information domain. Examples of objects in the modeling layer are, StockShare, askPrice, sellLimitOrder, and StockQuoteServer. User objects (a.k.a. user data) are an instance of a model. The primary responsibility of the user objects layer is to describe a specific information domain. Examples of objects in the user objects layer are: <Acme_Software_Share_98789>, 654.56, sell_limit_order, and <Stock_Quote_Svr_32123>.

4. Describe the following Behavioral Elements: o Common Behavior o Collaborations o Use Cases o State Machines Answer: (A)Common Behavior
Common Behavior

The Common Behavior package is the most fundamental of the subpackages that compose the Behavioral Elements package. It specifies the core concepts required for dynamic elements and provides the infrastructure to support Collaborations, State Machines, and Use Cases. Abstract Syntax: The abstract syntax for the Common Behavior package is expressed in graphic notation in the following figures. Figure 7.2 shows the model elements that define Signals and Receptions.

Figure 7.2: Common Behavior Signals

(B)Collaborations
Collaborations The Collaborations package is a subpackage of the Behavioral Elements package. The package uses constructs defined in the Foundation package and the Common Behavior packages. The Collaborations package provides the means to define Collaborations and CollaborationInstanceSets. The main constructs used in Collaboration include ClassifierRole, AssociationRole, Interaction, and Message while Instance, Stimulus, and Link are used in a CollaborationInstanceSet. The description of cooperating Instances involves two aspects: 1) the structural description of the participants, and 2) the description of their communication patterns. Collaboration includes a set of ClassifierRoles and AssociationRoles that define the participants needed for a given set of purposes. An Interaction specifies the communication patterns between the roles in the Collaboration. It contains a set of partially ordered Messages, each specifying one communication. A parameterized Collaboration represents a design construct that can be used repeatedly in different designs. The participants in the Collaboration, including the Classifiers and Relationships, can be parameters of the generic Collaboration. The parameters are bound to particular ModelElements in each instantiation of generic Collaboration. Such a parameterized Collaboration can capture the structure of a design pattern A Collaboration may be attached to an Operation or a Classifier, like a UseCase, to describe the realization of the Operation or of the Classifier; that is, what roles Instances play to perform the

behavior specified by the Operation or the UseCase. The Interactions defined within the Collaboration specify the communication pattern between the Instances when they perform the behavior specified in the Operation or the UseCase. Collaboration may also be attached to a Classifier to define the static structure of it; i.e., the roles played by the Attributes, the Parameters, etc. Collaboration is a GeneralizableElement. This implies that Collaboration may specify a task that is a specialization of another Collaborations task.

(C)Use Cases
The Use Cases package is a subpackage of the Behavioral Elements package. It specifies the concepts used for definition of the functionality of an entity like a system. The package uses constructs defined in the Foundation package of UML as well as in the Common Behavior package. The elements in the Use Cases package are primarily used to define the behavior of an entity without specifying its internal structure. The key elements in this package are UseCase and Actor. Instances of use cases and instances of actors interact when the services of the entity are used.

(D)State Machines
The State Machine package is a subpackage of the Behavioral Elements package. It specifies a set of concepts that can be used for modeling discrete behavior through finite state-transition systems. These concepts are based on concepts defined in the Foundation package as well as concepts defined in the Common Behavior package. This enables integration with the other subpackages in Behavioral Elements. The state machine formalism described in this section is an object-based variant of Harel statecharts. It incorporates several concepts similar to those defined in ROOMcharts, a variant of statechart defined in the ROOM modeling language. State machines can be used to specify behavior of various elements that are being modeled. For example, they can be used to model the behavior of individual entities (such as, class instances) or to define the interactions (such as, collaborations) between entities. In addition, the state machine formalism provides the semantic foundation for activity graphs. This means that activity graphs are simply a special form of state machines.

5. Describe the concept of Model Management in Object Oriented Systems. Answer:

Modeling is the process of describing an existing or proposed system. It can be used during any phase of the software life cycle. A model is an abstraction of a phenomenon for the purpose of understanding it. Since a model excludes unnecessary details, it is easier to manipulate than the real object. Modeling provides a means for communicating ideas in an easy way to understand and unambiguous form while also accommodating a systems complexity. 1986. Booch developed the object-oriented design concept, the Booch method. 1987. Sally Shlaer and Steve Mellor created the concept of the recursive design approach. 1989. Beck and Cunningham produced class-responsibility-collaboration cards. 1990. Wirfs-Brock, Wilkerson, and Wiener came up with responsibility-driven design. 1991. Jim Rumbaugh led a team at the research labs of General Electric to develop the object modeling technique (OMT). 1991. Peter Coad and Ed Yourdon developed the Coad lightweight and prototype-oriented approach to methods. 1994. Ivar Jacobson introduced the concept of the use case and object oriented software engineering (OOSE). The trend in object-oriented methodologies, sometimes called second-generation object-oriented methods, has been toward combining the best aspects of the most popular methods instead of coming out with new methodologies, which was the tendency in first-generation object-oriented methods. The Rumbaugh et al. method is well-suited for describing the object model or the static structure of the system. The Jacobson et al. method is good for producing user-driven analysis models. The Booch method produces detailed object-oriented design models. Objectives: After studying this unit, you will understand Rumbaughs Object Modeling Technique Booch Methodology Jacbosons methodology Patterns and Frameworks The Unified Approach

4.2 Rumbaugh et al.s Object Modeling Technique The Object Modeling Technique (OMT) presented by Jim Rumbaugh and his co-workers describes a method for the 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 OMTs functional model. OMT consists of four phases, which can be performed iteratively: 1. Analysis. The results are objects, 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 objects in a system: their identity, relationships to other object attributes, and operations. The object diagram contains classes interconnected by association lines. Each class represents a set of individual objects. 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.

Fig. 4.1: The OMT object model of a bank system. The boxes represent classes and the filled triangle represents specialization. Association between Account and Transaction is one to many; since one account can have many transactions, the filled circle represents many (zero or more). The relationship between Client and Account classes is one to one: A client can have only one account and account can belong to only one person (in this model joint accounts are not allowed). 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 the time it makes the transition to the next state. The next state depends on the current state as well as the events.

Fig. 4.2: State transition diagram for the bank application user interface. The round boxes represent states and the arrows represent transitions. The OMT functional model The OMT data flow diagram (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 et al. OMT methodology provides one of the strongest tool sets for the analysis and design of object-oriented systems.

Fig. 4.3: OMT DFD of the ATM system. The data flow lines include arrows to show the direction of data element movement. The circles represent processes. The boxes represent external entities. A data store reveals the storage of data. 4.3 The Booch Methodology The Booch methodology is a widely used object-oriented method that helps you to design your system using the object paradigm. The Booch method consists of the following diagrams: 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.

Fig. 4.4: Object modeling using Booch notation. The arrows represent specialization; for example, class Taurus is subclass of the class Ford.

Fig. 4.5: An alarm class state transition diagram with Booch notation. This diagram can capture the state of a class based on a stimulus. For example, a stimulus causes the class to perform some processing, followed by a transition to another state. In this case, the alarm silenced state can be changed to alarm sounding state and vice versa. 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: 1. 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. 2. 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. 3. 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. 4. Evolution or implementation: Successively refine the system through much iteration. Produce a stream of software implementations (or executable releases), each of which is a refinement of the prior one. 5. Maintenance: Make localized changes to the system to add new requirements and eliminate bugs.

The Micro development process Each macro development process has its own micro development processes. The micro development process consists of the following steps: 1. Identify classes and objects. 2. Identify class and object semantics. 3. Identify class and object relationships. 4. Identify class and object interfaces and implementation. 4.4 The Jacobson et al. methodologies The Jacobson et al. methodologies (e.g. Object-Oriented Business Engineering (OOBE), Object-Oriented Software Engineering (OOSE), and Object Factory for Software Development (Objectory)) 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 use case (like a subclass). The uses relationship reuses common behavior in different use 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.

6. Describe the following UML diagrams with suitable examples: o State chart diagrams o Activity diagrams Answer:
State Chart Diagrams A statechart diagram can be used to describe the behavior of instances of a model element such as an object or an interaction. Specifically, it describes possible sequences of states and actions through which the element instances can proceed during its lifetime as a result of reacting to discrete events (for example, signals, operation invocations). Statechart diagrams represent the behavior of entities capable of dynamic behavior by specifying its response to the receipt of event instances. Typically, it is used for describing the behavior of class instances, but statecharts may also describe the behavior of other entities such as use-cases, actors, subsystems, operations, or methods. Notation: A statechart diagram is a graph that represents a state machine. States and various other types of vertices (pseudostates) in the state machine graph are rendered by appropriate state and pseudostate symbols, while transitions are generally rendered by directed arcs that inter-

connect them. States may also contain subdiagrams by physical containment or tiling. Note that every state machine has a top state that contains all the other elements of the entire state machine. The graphical rendering of this top state is optional. The association between a state machine and its context does not have a special notation.

An example statechart diagram for a simple telephone object: Figure 11.1: State Diagram State: A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. A composite state is a state that, in contrast to a simple state, has a graphical decomposition. An object remains in a state for an interval of time. However, the semantics allow for modeling flow-through states that are instantaneous, as well as transitions that are not instantaneous. A state may be used to model an ongoing activity. Such an activity is specified either by a nested state machine or by a computational expression. Notation A state is shown as a rectangle with rounded corners. Optionally, it may have an attached name tab. The name tab is a rectangle, usually resting on the outside of the top side of a state and it contains the name of that state. It is normally used to keep the name of a composite state that has concurrent regions, but may be used in other cases as well. A state may be optionally subdivided into multiple compartments separated from each other by a horizontal line. They are as follows: Name compartment: This compartment holds the (optional) name of the state as a string. States without names are anonymous and are all distinct. It is undesirable to show the same named state twice in the same diagram, as confusion may ensue. Name compartments should not be used if a name tab is used and vice versa. internal transitions compartment: This compartment holds a list of internal actions or activities that are performed while the element is in the state. The action label identifies the circumstances under which the action specified by the action expression will be invoked. The action expression may use any attributes and links that are in the scope of the owning entity. For list items where the action expression is empty, the backslash separator is optional. A number of action labels are reserved for various special purposes and, therefore, cannot be used as event names. The following are the reserved action labels and their meaning:

 entry: This label identifies an action, specified by the corresponding action expression, which is performed upon entry to the state (entry action). exit: This label identifies an action, specified by the corresponding action expression, that is performed upon exit from the state (exit action). Do: This label identifies an ongoing activity (do activity) that is performed as long as the modeled element is in the state or until the computation specified by the action expression is completed (the latter may result in a completion event being generated). Include: This label is used to identify a submachine invocation. The action expression contains the name of the submachine that is to be invoked. In all other cases, the action label identifies the event that triggers the corresponding action expression. These events are called internal transitions and are semantically equivalent to self transitions except that the state is not exited or re-entered. This means that the corresponding exit and entry actions are not performed. The general format for the list item of an internal transition is: event-name (comma-separated-parameter-list) [ guard-condition] / actionexpression Each event name may appear more than once per state if the guard conditions are different. The event parameters and the guard conditions are optional. If the event has parameters, they can be used in the action expression through the current event variable. Example

Activity Diagrams
An activity graph is a variation of a state machine in which the states represent the performance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities. It represents a state machine of a procedure itself. An activity diagram is a special case of a state diagram in which all (or at least most) of the states are action or subactivity states and in which all (or at least most) of the transitions are triggered by completion of the actions or subactivities in the source states. The entire activity diagram is attached (through the model) to a classifier, such as a use case, or to a package, or to the implementation of an operation. The purpose of this diagram is to focus on flows driven by internal processing (as opposed to external events). Use activity diagrams in situations where all or most of the events represent the

completion of internally-generated actions (that is, procedural flow of control). Use ordinary state diagrams in situations where asynchronous events occur. Example

Figure 11.13: Activity Diagram Action State : An action state is a shorthand for a state with an entry action and at least one outgoing transition involving the implicit event of completing the entry action (there may be several such transitions if they have guard conditions). Action states should not have internal transitions, outgoing transitions based on explicit events, or exit actions, use normal states for this situation. Transitions leaving an action state should not include an event signature. Such transitions are implicitly triggered by the completion of the action in the state. The transitions may include guard conditions and actions. The normal use of an action state is to model a step in the execution of an algorithm (a procedure) or a workflow process. Notation An action state is shown as a shape with straight top and bottom and with convex arcs on the two sides. The action-expression is placed in the symbol. The action expression need not be unique within the diagram. The action may be described by natural language, pseudocode, or programming language code. It may use only attributes and links of the owning object. The action state notation may be used within ordinary state diagrams; however, they are more commonly used with activity diagrams, which are special cases of state diagrams.