February 2010 Master of Computer Application (MCA) Semester 5 MC0083 Object Oriented Analysis & Design using UML

ML 4 Credits
(Book ID: B0969)

Assignment Set 1 (60 Marks)

Answer all Questions 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. 1.4 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.

Each question carries TEN Marks

1. Describe the theory behind Object oriented systems development methodology.

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 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 objects 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 objects state. In particular, the identity does not depend on the objects name, or its key, or its location.

Fig. 1.1 the owner property of a car contains a reference to the person instance named Jon (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: A description in terms of how it works Specification of the input required for the process 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 Transformation 1 (analysis) translates the users needs into system requirements and responsibilities.

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

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: How do we determine that the system is ready for delivery? Is it now an operational system that satisfies users needs? Is it correct and operating as we thought it should? Does it pass an evaluation process? Blum describes a means of system evaluation in terms of four quality measures: Correspondence measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement. Validation task of predicting correspondence. Correctness measures the consistency of the product requirements with respect to the design specification. Verification exercise of determining correctness. Verification: Am I building the product right? Validation: Am I building the right product? Validation begins as soon as the project starts, but verification can begin only after a specification has accepted. been

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 objectoriented 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:

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. 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: Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns but the reverse is never true. Design patterns are less specialized than frameworks

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

Goals of the UML The primary design goals of the UML are as follows:

Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models. Furnish extensibility and specialization mechanisms to extend the core concepts. Support specifications that are independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the object tools market. Support higher-level development concepts such as components, collaborations, frameworks and patterns. Integrate 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 communitys consensus on core modeling concepts. It allows deviations to be expressed in terms of its extension mechanisms. The Unified Modeling Language provides the following: Semantics and notation to address a wide variety of contemporary modeling issues in a direct and economical fashion. Semantics to address certain expected future modeling issues, specifically related to component technology, distributed computing, frameworks, and executability. Extensibility mechanisms so individual projects can extend the metamodel for their application at low cost. We dont want users to directly change the UML metamodel. Extensibility mechanisms so that future modeling approaches could be grown on top of the UML. Semantics to facilitate model interchange among a variety of tools. Semantics to specify the interface to repositories for the sharing and storage of model artifacts Outside the Scope of the UML Programming Languages: The UML, a visual modeling language, is not intended to be a visual programming language, in the sense of having all the necessary visual and semantic support to replace programming languages. The UML is a language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system, but it does draw the line as you move toward code. For example, complex branches and joins are better expressed in a textual programming language. The UML does have a tight mapping to a family of object languages so that you can get the best of both worlds. Tools:

Standardizing a language is necessarily the foundation for tools and process. Tools and their interoperability are very dependent on a solid semantic and notation definition, such as the UML provides. The UML defines a semantic meta model, not a tool interface, storage, or run-time model, although these should be fairly close to one another. The UML documents do include some tips to tool vendors on implementation choices, but do not address everything needed. For example, they dont address topics like diagram coloring, user navigation, animation, storage/ implementation models, or other features. Process: Many organizations will use the UML as a common language for its project artifacts, but will use the same UML diagram types in the context of different processes. The UML is intentionally process independent, and defining a standard process was not a goal of the UML or OMGs RFP. The UML authors do recognize the importance of process. The presence of a well defined and well-managed process is often a key discriminator between hyper productive projects and unsuccessful ones. The reliance upon heroic programming is not a sustainable business practice. A process Provides guidance as to the order of a teams activities, Specifies what artifacts should be developed, Directs the tasks of individual developers and the team as a whole, and Offers criteria for monitoring and measuring a projects products and activities.

Processes by their very nature must be tailored to the organization, culture, and problem domain at hand. What works in one context (shrink-wrapped software development, for example) would be a disaster in another (hardreal-time, human-rated systems, for example). The selection of a particular process will vary greatly, depending on such things as problem domain, implementation technology, and skills of the team. Booch, OMT, OOSE, and many other methods have well-defined processes, and the UML can support most methods. There has been some convergence on development process practices, but there is not yet consensus for standardization. What will likely result is general agreement on best practices and potentially the embracing of a process framework, within which individual processes can be instantiated. Although the UML does not mandate a process, its developers have recognized the value of a use-case driven, architecture-centric, iterative, and incremental process, so were careful to enable (but not require) this with the UML.

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: 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 fourlayer 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

Layer meta-metamodel

Metamodel

Model

user objects (user data)

<Acme_SW_Share_9878 9>, 654.56, sell_limit_order, <Stock_Quote_Svr_3212 3> 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. (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 metamodel is decomposed into the top-level packages as shown in

Description The infrastructure for a meta modeling architecture. Defines the language for specifying metamodels. An instance of a metametamodel. Defines the language for specifying a model. An instance of a metamodel. Defines a language to describe an information domain. An instance of a model. Defines a specific information domain.

Example MetaClass, MetaAttribute, MetaOperation Class, Attribute, Operation, Component StockShare, askPrice, sellLimitOrder, StockQuoteServer

Fig 6.1 The Foundation and Behavioral Elements packages are further decomposed as shown in Figure 6-2 and

Fig 6.2 (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:

When referring to constructs in UML, not their representation in the metamodel, normal text is used. Metaclass names that consist of appended nouns/adjectives, initial embedded capitals are used (for example, ModelElement, StructuralFeature). Names of metaassociations/association classes are written in the same manner as metaclasses (for example, ElementReference). Initial embedded capital is used for names that consist of appended nouns/adjectives (for example, ownedElement, allContents). Boolean metaattribute names always start with is (for example, isAbstract). Enumeration types always end with Kind (for example, AggregationKind). While referring to metaclasses, metaassociations, metaattributes, etc. in the text, the exact names as they appear in the model are always used. Names of stereotypes are delimited by guillemets and begin with lowercase (for example, type).

February 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.
Graphs and Their Contents Most UML diagrams and some complex symbols are graphs containing nodes connected by paths. The information is mostly in the topology, not in the size or placement of the symbols (there are some exceptions, such as a sequence diagram with a metric time axis). There are three kinds of visual relationships that are important: 1. connection (usually of lines to 2-d shapes), 2. Containment (of symbols by 2-d shapes with boundaries), and 3. visual attachment (one symbol being near another one on a diagram). These visual relationships map into connections of nodes in a graph, the parsed form of the notation. UML notation is intended to be drawn on 2dimensional surfaces. Some shapes are 2dimensional projections of 3-d shapes (such as cubes), but they are still rendered as icons on a 2-dimensional surface. In the near future, true 3-dimensional layout and navigation may be possible on desktop machines; however, it is not currently practical. There are basically four kinds of graphical constructs that are used in UML notation: 1. Icons An icon is a graphical figure of a fixed size and shape. It does not expand to hold contents. Icons may appear within area symbols, as terminators on paths or as standalone symbols that may or may not be connected to paths. 2. 2D Symbols Two-dimensional symbols have variable height and width and they can expand to hold other things, such as lists of strings or other symbols. Many of them are divided into compartments of similar or different kinds. Paths are connected to two-dimensional symbols by terminating the path on the boundary of the symbol. Dragging or deleting a 2-d symbol affects its contents and any paths connected to it. 3. Paths Sequences of line segments whose endpoints are attached. Conceptually a path is a single topological entity, although its segments may be manipulated graphically. A segment may not exist apart from its path. Paths are always attached to other graphic symbols at both ends (no dangling lines). Paths may have terminators; that is, icons that appear in some sequence on the end of the path and that qualify the meaning of the path symbol. 4. Strings Present various kinds of information in an unparsed form. UML assumes that each usage of a string in the notation has a syntax by which it can be parsed into underlying model information. For example, syntaxes are given for attributes, operations, and transitions. These syntaxes are subjected to extension by tools as a

presentation option. Strings may exist as singular elements of symbols or compartments of symbols, as elements in lists (in which case the position in the list conveys information), as labels attached to symbols or paths, or as standalone elements on a diagram.

2. Describe the theory along with real time examples of the following concepts: A) Nested Class Declarations, Type and Implementation Class
A class declared within another class belongs to the namespace of the other class and may only be used within it. A declaring class and a class in its namespace may be connected by a line, with an anchor icon on the end connected to a declaring class. An anchor icon is a cross inside a circle. The contents of the package are declared within the class and belong to its namespace.

Declaring Class

Nested Class

A Type is used to specify a domain of objects together with operations applicable to the objects without defining the physical implementation of those objects. A Type may not include any methods, but it may provide behavioral specifications for its operations. An implementation class defines the physical data structure and methods of an object.

B) Interfaces and Parameterized Class (Template)

An interface is shown using the full rectangle symbol with compartments and the keyboard <<interface>>. A list of operations supported by the interface is placed in the operation compartment. The attribute compartment may be omitted since it is always empty. An interface may also be displayed as a small circle with the name of the interface placed below the symbol.

store poSterminal Home

Store -storeld: Integer -POS list: List +create() +login(Username,password) +find(Storeld) +getPostota is(POSid) +updateStore Totals(Id,Sales) +get(Item)

Pos Terminal

<<interface>> Store + getPOStota Is(POSid) +updateStore Totals(Id,Sales) +get(Item)

posterminal

Parameterized class: A small dashed rectangle is superimposed on the upper right-hand corner of the rectangle for the class. The dashed rectangle contains a parameter list of formal parameters for the class and their implementation types. The dashed rectangle contains a parameter list of formal parameters for the class and their implementation types. The list must not be empty, although it might be suppressed in the presentation.

FArray k..k T

T.k: Integer

<<bind>> (Address,24)

FArray<Point,3>

AddressList

3. Describe the following UML diagrams with real time examples: A) Sequence Diagrams
A sequence diagram presents an Interaction, which is a set of Messages between ClassifierRoles within a Collaboration, or an Interaction InstanceSet, which is a set of Stimuli between Instances within a CollaborationInstanceSet to effect a desired operation or result. Notation: A sequence diagram has two dimensions: 1) the vertical dimension represents time and 2) the horizontal dimension represents different instances. Normally time proceeds down the page. (The dimensions may be reversed, if desired.) Usually only time sequences are important, but in real-time applications the time axis could be an actual metric. There is no significance to the horizontal ordering of the instances.

B) Collaboration Diagrams

A collaboration diagram presents either a Collaboration, which contains a set of roles to be played by Instances, as well as their required relationships given in a particular context, or it presents a CollaborationInstanceSet with a collection of Instances and their relationships. The diagram may also present an Interaction (InteractionInstanceSet), which defines a set of Messages (Stimuli) specifying the interaction between the Instances playing the roles within a Collaboration to achieve the desired result. A Collaboration is used for describing the realization of an Operation or a Classifier. A Collaboration that describes a Classifier, like a UseCase, references Classifiers and Associations in general, while a Collaboration describing an Operation includes the arguments and local variables of the Operation, as well as ordinary Associations attached to the Classifier owning the Operation. Notation: A collaboration diagram shows a graph of either Instances linked to each other, or ClassifierRoles and AssociationRoles; it may also include the communication stated by an Interaction or InteractionInstanceSet. Because collaboration diagrams often are used to help design procedures, they typically show navigability using arrowheads on the lines representing Links or AssociationRoles. (An arrowhead on a line between boxes indicates a Link or AssociationRole with one-way navigability. An arrow next to a line indicates Stimuli or Message flowing in the given direction. Obviously such an arrow cannot point backwards over a one-way line.) The order of the interaction is described with a sequence of numbers, usually starting with number. For a procedural flow of control, the subsequent communication numbers are nested in accordance with call nesting. For a nonprocedural sequence of interactions among concurrent instances, all the sequence numbers are at the same level (that is, they are not nested). A collaboration diagram without any interaction shows the context in which interactions can occur. It might be used to show the context for a single Operation or even for all of the Operations of a Class or group of Classes. A collection of standard constraints may be used to show whether an Instance or a Link is created or destroyed during the execution: Instances and Links created during the execution may be designated as {new}. Instances and Links destroyed during the execution may be designated as {destroyed}. Instances and Links created during the execution and then destroyed may be designated as {transient}. These changes in life state are derivable from the detailed interaction among the Instances, they are provided as notational conveniences.

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

Introduction The UML Profile for Business Modeling is an example profile that describes how UML can be customized for business modeling. Although all UML concepts can be brought to bear on this domain, but example emphasizes common stereotypes and some useful terminology. Note that UML can be used to model different kinds of systems (such as software systems, hardware systems, and real-world organizations). This is defined only through stereotypes and constraints; profiles also commonly include tagged values. Summary of Profile The stereotypes that are defined by this profile are summarized in the table below Stereotype Base Class UseCaseModel Model

UseCaseSystem Package UseCasePackage Package ObjectModel Model ObjectSystem Subsystem OrganizationUnit Subsystem WorkUnit Subsystem Worker Class CaseWorker Class InternalWorker Class Entity Class Communicate Association Subscribe Association Stereotypes and Notation: A business system comprises several different, but related, models. The models are characterized by being exterior or interior to the business system they represent. Exterior models are use case models and interior models are object models. A large business system may be partitioned into subordinate business systems. Use Case Stereotypes Use Case Model: A use case model is a model that describes the business processes of a business and their interactions with external parties such as customers and partners. A use case model describes: The business modeled as use cases Parties exterior to the business modeled as actors The relationships between the external parties and the business process The notation used for a UseCaseModel is a package stereotyped as useCaseModel. Base Class is Model. UseCaseSystem: A use case system is the top-level package in a use case model, and may contain use case packages, use cases, and relationships. The notation used for a UseCaseSystem is a package stereotyped as useCaseSystem. Base Class is Package. UseCasePackage: A use case package is a package that may contain use cases and relationships. The notation used for a UseCasePackage is a package stereotyped as useCasePackage. Base Class is Package. Organization Stereotypes ObjectModel: An object model is a model whose top-level package is an object system that describe the things interior to the business system itself. The notation used for an ObjectModel is a package stereotyped as objectModel. Base Class is Model. ObjectSystem: An object system is the top-level subsystem in an object model, and may contain organization units, work units, classes, and relationships. The notation used for an ObjectSystem is a package stereotyped as objectSystem. Base Class is Subsystem. OrganizationUnit: An organization unit is a subsystem that may contain other organization units, work units, classes, and relationships. The notation used for an OrganizationUnit is a package stereotyped as organizationUnit. Base Class is Subsystem. WorkUnit: A work unit is a subsystem that may contain one or more entities. It is a task-oriented set of objects that forms a recognizable whole to the end user, and may have a faade defining the view of the work units entities relevant to the task. The notation used for a WorkUnit is a package stereotyped as workUnit. Base Class is Subsystem.

Class Stereotypes Worker: A worker is a class that represents an abstraction of a human that acts within the system. A worker interacts with other workers and manipulates entities while participating in use case realizations. The notation for Worker is worker. Base Class is Class. CaseWorker: A case worker is a special case of worker that interacts directly with actors outside the system. The notation for CaseWorker is caseWorker. CaseWorker is not stereotyped of a UML metaclass, but rather inherits its properties from the stereotype Worker that was previously defined. The explicit subtyping of a stereotype is shown in Figure

InternalWorker : The notation for InternalWorker is shown below. Note that InternalWorker, like CaseWorker above, is subtyped from the previously defined stereotype Worker. Base Class is Class. Notation: The notation given as part of the UML specification for stereotyped classes can be used for entity, control, and boundary, but it is also possible to substitute that notation with the icons shown below.

Association Stereotypes Communicate: Communicate is an association used for defining the instances of the associated classifiers interact. The notation used for Communicate is an association that is marked with the stereotype communicate. Base Class is Association. Subscribe: A subscribe association between two classes states that objects of the source class (called the subscriber) will be notified when a particular event has occurred in objects of the target class (called the publisher). The association includes a specification of a set of events defining the event that causes the subscriber to be notified. The notation used for Subscribe is an association that is marked with the stereotype subscribe. Base Class is Association

5. Explain the following with respect to Object Constraint Language: A) Basic Values and Types
In OCL, a number of basic types are predefined and available to the modeler at all times. These predefined value types are independent of any object model and part of the definition of OCL. The most basic value in OCL is a

value of one of the basic types. Some basic types used in the examples in this document, with corresponding examples of their values, are shown in Table Type Values Integer 1, 5, 2, 34, 26524, Real 1.5, 3.14, Boolean true, false String To UPPER(), concat Types from the UML Model: Each OCL expression is written in the context of a UML model, a number of classifiers (types/classes ...), their features and associations, and their generalizations. All classifiers from the UML model are types in the OCL expressions that are attached to the model.

B) Objects and Properties

OCL expressions can refer to Classifiers; for example, types, classes, interfaces, associations (acting as types), and data types. Also all attributes, association-ends, methods, and operations without side-effects that are defined on these types, etc. can be used. In a class model, an operation or method is defined to be side-effect-free if the is Query attribute of the operations is true. For the purpose of this document, we will refer to attributes, associationends, and side-effect-free methods and operations as being properties. A property is one of: An Attribute An Association End An Operation with isQuery being true A Method with isQuery being true

Properties: The value of a property on an object that is defined in a class diagram is specified by a dot followed
by the name of the property. Context AType inv : self. Property If self is a reference to an object, then self.property is the value of the property property on self. Properties: Attributes : For example, the age of a Person is written as self.age: context Person inv : self.age > 0 The value of the sub expression self.age is the value of the age attribute on the particular instance of Person identified by self. The type of this sub expression is the type of the attribute age, which is the basic type Integer. Using attributes, and operations defined on the basic value types, we can express calculations etc. over the class model. For example, a business rule might be the age of a Person is always greater than zero. This can be stated as shown in the invariant above.

6. Explain the theory of Collection Operations with respect to Object Constraint Language Specification.
OCL defines many operations on the collection types. These operations are specifically meant to enable a flexible and powerful way of projecting new collections from existing ones. Select and Reject Operations: Sometimes an expression using operations and navigations delivers a collection, while we are interested only in a special subset of the collection. OCL has special constructs to specify a selection from a specific collection. These are the select and reject operations. The select specifies a subset of a collection. A select is an operation on a collection and is

specified using the arrow-syntax: collection->select( ... ) The parameter of select has a special syntax that enables one to specify which elements of the collection we want to select. There are three different forms, of which the simplest one is : collection->select( boolean- expression ) This results in a collection that contains all the elements from collection for which the boolean-expression evaluates to true. To find the result of this expression, for each element in collection the expression booleanexpression is evaluated. If this evaluates to true, the element is included in the result collection, otherwise not. As an example, the following OCL expression specifies that the collection of all the employees older than 50 years is not empty: context Company inv: self.employee->select(age > 50)->notEmpty() The self.employee is of type Set(Person). The select takes each person from self.employee and evaluates age > 50 for this person. If this results in true, then the person is in the result Set. As shown in the previous example, the context for the expression in the select argument is the element of the collection on which the select is invoked. Thus the age property is taken in the context of a person. In the above example, it is impossible to refer explicitly to the persons themselves; you can only refer to properties of them. To enable to refer to the persons themselves, there is a more general syntax for the select expression: collection->select( v | boolean-expression-with-v ) The variable v is called the iterator. When the select is evaluated, v iterates over the collection and the boolean-expression-with-v is evaluated for each v. The v is a reference to the object from the collection and can be used to refer to the objects themselves from the collection. The two examples below are identical: context Company inv: self.employee->select(age > 50)->notEmpty() context Company inv: self.employee->select(p | p.age > 50)->notEmpty() The result of the complete select is the collection of persons p for which the p.age > 50 evaluates to True. This amounts to a subset of self.employee. As a final extension to the select syntax, the expected type of the variable v can be given. The select now is written as: collection->select( v : Type | boolean-expression-with-v ) The meaning of this is that the objects in collection must be of type Type. The next example is identical to the previous examples: context Company inv: self.employee.select(p : Person | p.age > 50) ->notEmpty() The compete select syntax now looks like one of: collection->select( v : Type | boolean-expression-with-v ) collection->select( v | boolean-expression-with-v ) collection->select( boolean-expression ) The reject operation is identical to the select operation, but with reject we get the subset of all the elements of the collection for which the expression evaluates to False. The reject syntax is identical to the select syntax: collection->reject( v : Type | boolean-expression-with-v ) collection->reject( v | boolean-expression-with-v ) collection->reject( boolean-expression ) As an example, specify that the collection of all the employees who are not married is empty: context Company inv: self.employee->reject( isMarried )->isEmpty() The reject operation is available in OCL for convenience, because each reject can be restated as a select with the negated expression. Therefore, the following two expressions are identical: collection->reject( v : Type | boolean-expression-with-v )

collection->select( v : Type | not (boolean-expression-with-v) )