UGC NET STUDY MATERIALS

MC0083 – Object Oriented Analysis & Design using UML

August 2010
Master of Computer Application (MCA) – Semester 5
MC0083 – Object Oriented Analysis &
Design using UML– 4 Credits
(Book ID: B0969)
Assignment Set – 1 (60 Marks)

Answer all Questions Each question carries TEN Marks

1. Describe the theory behind Object oriented systems development methodology.
Object oriented systems development methodology
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”. In an object oriented system, everything is an object and each object is responsible for itself. In a payroll application, instead of saying, “System, compute the payroll of this employee”, you tell the employee object, “Compute your payroll”.

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.

1. 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.

2. 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.

3. 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.

4. Promotion of reusability: Objects are reusable because they are modeled directly out of real-world 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 with suitable examples:

A) Object and Identity :A special feature of object-oriented systems is that every object has its own unique and immutable identity. An object’s identity comes into being when the object is created and continues to represent that object from then on. This identity never is confused with another object, even if the original object has been deleted. The identity name never changes even if all the properties of the object change – it is independent of the object’s state. In particular, the identity does not depend on the object’s name, or its key, or its location.

B) 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.

C) 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.

D) 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 following with suitable real time examples:

A) The software development process:
System development can be viewed as a process. Furthermore, the development itself, in essence, is a process of change, refinement, transformation, or addition to existing product. The process can be divided into small, interacting phases – subprocesses. Each subprocess must have the following:

1. A description in terms of how it works


2. Specification of the input required for the process


3. Specification of the output to be produced

Generally, the software development process can be viewed as a series of transformations, where the output of one transformation becomes the input of the subsequent transformation

1. Transformation 1 (analysis) – translates the users’ needs into system requirements and responsibilities.

2. Transformation 2 (design) – begins with a problem statement and ends with a detailed design that can be transformed into an operational system.

3. Transformation 3 (implementation) – refines the detailed design into the system deployment that will satisfy users’ needs.

An example of the software development process is the waterfall approach, which starts with deciding what is to be done. Once the requirements have been determined, we next must decide how to accomplish them. This is followed by a step in which we do it, whatever “it” has required us to do. We then must test the result to see if we have satisfied the users’ requirements. Finally, we use what we have done.
In the real world, the problems are not always well-defined and that is why the waterfall model has limited utility.




B) Building high-quality software:

To achieve high quality in software we should be able to answer the following questions:

1. How do we determine that the system is ready for delivery?


2. Is it now an operational system that satisfies users’ needs?


3. Is it correct and operating as we thought it should?


4. Does it pass an evaluation process?

Blum describes a means of system evaluation in terms of four quality measures:

1. Correspondence – measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement.

2. Validation – task of predicting correspondence.

3. Correctness – measures the consistency of the product requirements with respect to the design specification.

4. Verification – exercise of determining correctness.

Verification: Am I building the product right?
Validation: Am I building the right product?

5. Validation begins as soon as the project starts, but verification can begin only after a specification has been accepted.



4. Describe the following Object Oriented Methodologies:

A) Patterns: 

Pattern identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. It identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.
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.
A pattern involves a general description of a solution to a recurring problem bundle with various goals and constraints. But a pattern does more than just identify a solution; it also explains why the solution is needed. However, not every solution, algorithm, best practice, maxim, or heuristic constitutes a pattern (one or more key pattern ingredients may be absent). Even if something appears to have all the requisite pattern components, it should not be considered as a pattern until it has been verified to be a recurring phenomenon (preferably found in at least three existing systems; this often is called the rule of three). A “pattern in waiting”, which is not yet known to recur, sometimes is called a proto-pattern.
Coplien explains that a good pattern will do the following:


1. It solves a problem. Patterns capture solutions, not just abstract principles or strategies.


2. It is a proven concept. Patterns capture solutions with a track record, not theories or speculation.


3. 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.


4. It describes a relationship. Patterns do not just describe modules, but describe deeper system structures and mechanisms.


5. 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.

Generative and Non-generative Patterns:

Generative patterns are patterns that not only describe a recurring problem; they can tell us how to generate something and can be observed in the resulting system architectures. Generative patterns are dynamic.
Non-generative patterns are static and passive: They describe recurring phenomena without necessarily saying how to reproduce them.
The successive application of several patterns, each encapsulating its own problem and forces, unfolds a larger solution, which emerges indirectly as a result of the smaller solutions. It is the generation of such emergent behavior that appears to be what is meant by generativity.


B) Frameworks :
A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a development.
A framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by sub-classing and composing instances of framework classes. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework usually includes concrete subclasses which you can put to work immediately.
A framework is executable software, whereas design patterns represent knowledge and experience about software.
Gamma et al. describe the major differences between design patterns and frameworks as follows:

1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code.


2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns but the reverse is never true.


3. Design patterns are less specialized than frameworks.


5. Describe the goals and scope of UML with suitable examples.

The primary design goals of the UML are as follows:
1. Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models.
2. Furnish extensibility and specialization mechanisms to extend the core concepts.
3. Support specifications that are independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the object tools market.
6. Support higher-level development concepts such as components, collaborations, frameworks and patterns.
7. Integrate best practices.

These goals are discussed in detail below.
Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models
It is important that the Object Analysis and Design (OA&D) standard support a modeling language that can be used ―out of the box‖ to do normal general-purpose modeling tasks. If the standard merely provides a meta-meta-description that requires tailoring to a particular set of modeling concepts, then it will not achieve the purpose of allowing users to exchange models without losing information or without imposing excessive work to map their models to a very abstract form. The UML consolidates a set of core modeling concepts that are generally accepted across many current methods and modeling tools. These concepts are needed in many or most large applications, although not every concept is needed in every part of every application. Specifying a meta-meta-level format for the concepts is not sufficient for model users, because the concepts must be made concrete for real modeling to occur. If the concepts in different application areas were substantially different, then such an approach might work, but the core concepts needed by most application areas are similar and should be supported directly by the standard without the need for another layer.
Furnish extensibility and specialization mechanisms to extend the core concepts
OMG expects that the UML will be tailored as new needs are discovered and for specific domains. At the same time, we do not want to force the common core concepts to be redefined or re-implemented for each tailored area. Therefore, we believe that the extension mechanisms should support deviations from the common case, rather than being required to implement the core modeling concepts themselves. The core concepts should not be changed more than necessary. Users need to be able to :
• build models using core concepts without using extension mechanisms for most normal applications,
• add new concepts and notations for issues not covered by the core,
• choose among variant interpretations of existing concepts, when there is no clear consensus,
• specialize the concepts, notations, and constraints for particular application domains.

Support specifications that are independent of particular programming languages and development processes
The UML must and can support all reasonable programming languages. It must also and can support various methods and processes of building models. The UML can support multiple programming languages and development methods without excessive difficulty.
Provide a formal basis for understanding the modeling language
Because users will use formality to help to understand the language, it must be both precise and approachable; a lack of either dimension damages its usefulness. The formalisms must not require excessive levels of indirection or layering, use of low level mathematical notations distant from the modeling domain, such as set-theoretic notation, or operational definitions that are equivalent to programming an implementation. The UML provides a formal definition of the static format of the model using a meta model expressed in UML class diagrams. This is a popular and widely accepted formal approach for specifying the format of a model and directly leads to the implementation of interchange formats. UML expresses well-formed constraints in precise natural language plus Object Constraint Language expressions. UML expresses the operational meaning of most constructs in precise natural language. The fully formal approach taken to specify languages such as Algol-68 was not approachable enough for most practical usage.
Encourage the growth of the object tools market
By enabling vendors to support a standard modeling language used by most users and tools, the industry benefits. While vendors still can add value in their tool implementations, enabling interoperability is essential. Interoperability requires that models can be exchanged among users and tools without loss of information. This can only occur if the tools agree on the format and meaning of all the relevant concepts. Using a higher meta-level is no solution unless the mapping to the user-level concepts is included in the standard.
Support higher-level development concepts such as components, collaborations, frameworks, and patterns
Clearly defined semantics of these concepts is essential to reap the full benefit of object-orientation and reuse. Defining these within the holistic context of a modeling language is a unique contribution of the UML.

Integrate best practices 

A key motivation behind the development of the UML has been to integrate the best practices in the industry, encompassing widely varying views based on levels of abstraction, domains, architectures, life cycle stages, implementation technologies, etc. The UML is indeed such an integration of best practices.

Scope of the UML:

The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system.
First and foremost, the Unified Modeling Language fuses the concepts of Booch, OMT, and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods.
Secondly, the Unified Modeling Language pushes the envelope of what can be done with existing methods. As an example, the UML authors targeted the modeling of concurrent, distributed systems to assure the UML adequately addresses these domains.
Thirdly, the Unified Modeling Language focuses on a standard modeling language, not a standard process. Although the UML must be applied in the context of a process, it is our experience that different organizations and problem domains require different processes. (For example, the development process for shrink-wrapped software is an interesting one, but building shrink-wrapped software is vastly different from building hard-real-time avionics systems upon which lives depend.) Therefore, the efforts concentrated first on a common metamodel (which unifies semantics) and second on a common notation (which provides a human rendering of these semantics). The UML authors promote a development process that is use-case driven, architecture centric, and iterative and incremental.
The UML specifies a modeling language that incorporates the object-oriented community’s consensus on core modeling concepts. It allows deviations to be expressed in terms of its extension mechanisms. The Unified Modeling Language provides the following:


1. Semantics and notation to address a wide variety of contemporary modeling issues in a direct and economical fashion.


2. Semantics to address certain expected future modeling issues, specifically related to component technology, distributed computing, frameworks, and executability.


3. Extensibility mechanisms so individual projects can extend the metamodel for their application at low cost. We don’t want users to directly change the UML metamodel.


4. Extensibility mechanisms so that future modeling approaches could be grown on top of the UML.


5. Semantics to facilitate model interchange among a variety of tools.


6. Semantics to specify the interface to repositories for the sharing and storage of model artifacts.



6. Explain the following with respect to UML Architecture:

A) 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:

1. It refines semantic constructs by recursively applying them to successive meta layers.


2. It provides an architectural basis for defining future UML meta model extensions.


3. 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:


1. meta-meta model


2. meta model


3. model


4. user objects


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: , 654.56, sell_limit_order, and .

B) Package Structure:

 
The complexity of the UML metamodel is managed by organizing it into logical packages. These packages group metaclasses that show strong cohesion with each other and loose coupling with metaclasses in other packages.

The Foundation and Behavioral Elements packages are further decomposed as :

  • Foundation Packages
  • Behavioral Elements Packages

C) Levels of Formalism :
A common technique for specification of languages is to first define the syntax of the language and then to describe its static and dynamic semantics. The syntax defines what constructs exist in the language and how the constructs are built up in terms of other constructs. Sometimes, especially if the language has a graphic syntax, it is important to define the syntax in a notation independent way, that is, to define the abstract syntax of the language. The concrete syntax is then defined by mapping the notation onto the abstract syntax. The static semantics of a language define how an instance of a construct should be connected to other instances to be meaningful, and the dynamic semantics define the meaning of a well-formed construct. The meaning of a description written in the language is defined only if the description is well formed, that is, if it fulfills the rules defined in the static semantics.
The specification uses a combination of languages – a subset of UML, an object constraint language, and precise natural language to describe the abstract syntax and semantics of the full UML.
In constructing the UML metamodel different techniques have been used to specify language constructs, using some of the capabilities of UML. The main language constructs are reified into metaclasses in the metamodel. Other constructs, in essence being variants of other ones, are defined as stereotypes of metaclasses in the metamodel. This mechanism allows the semantics of the variant construct to be significantly different from the base metaclass. Another more “lightweight” way of defining variants is to use metaattributes. As an example, the aggregation construct is specified by an attribute of the metaclass AssociationEnd, which is used to indicate if an association is an ordinary aggregate, a composite aggregate, or a common association.

D) Naming Conventions and Typography

In the description of UML, the following conventions have been used:

1. When referring to constructs in UML, not their representation in the metamodel, normal text is used.

2. Metaclass names that consist of appended nouns/adjectives, initial embedded capitals are used (for example, „ModelElement,‟ „StructuralFeature‟).

3. Names of metaassociations/association classes are written in the same manner as metaclasses (for example, „ElementReference‟).

4. Initial embedded capital is used for names that consist of appended nouns/adjectives (for example, „ownedElement,‟ „allContents‟).

5. Boolean metaattribute names always start with „is‟ (for example, „isAbstract‟).

6. Enumeration types always end with “Kind” (for example, „AggregationKind‟).

7. While referring to metaclasses, metaassociations, metaattributes, etc. in the text, the exact names as they appear in the model are always used.

8. Names of stereotypes are delimited by guillemets and begin with lowercase (for example, «type»).






August 2010
Master of Computer Application (MCA) – Semester 5
MC0083 – Object Oriented Analysis &
Design using UML– 4 Credits
(Book ID: B0969)
Assignment Set – 2 (60 Marks)

Answer all Questions Each question carries TEN Marks
1. Illustrate various Diagram Elements in the context of UML Notation guide.

2. Describe the theory along with real time examples of the following concepts:
A) Nested Class Declarations, Type and Implementation Class
B) Interfaces and Parameterized Class (Template)

3. Describe the following UML diagrams with real time examples:
A) Sequence Diagrams B) Collaboration Diagrams

4. Explain the theory of UML Profile for Business Modeling.

5. Explain the following with respect to Object Constraint Language:
A) Basic Values and Types B) Objects and Properties

6. Explain the theory of Collection Operations with respect to Object Constraint Language Specification.



Popular Posts

Recent Posts