February 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”. 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.

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

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

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

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 don’t 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 don’t 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 OMG’s 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 team’s 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 project’s 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 (hard-real-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 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 ArchitectureLayer Description Example meta-metamodel The infrastructure for a

meta modeling architecture. Defines the language for specifying

MetaClass, MetaAttribute, MetaOperation

metamodels. Metamodel An instance of a

metametamodel. Defines the language for specifying a model.

Class, Attribute, Operation, Component

Model An instance of a metamodel. Defines a language to describe an information domain.

StockShare, askPrice, sellLimitOrder, StockQuoteServer

user objects (user data) An instance of a model. Defines a specific information domain.

<Acme_SW_Share_98789>, 654.56, sell_limit_order, <Stock_Quote_Svr_32123>

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

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 2-dimensional surfaces. Some shapes are 2–dimensional 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. 2–D 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 stand-

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

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

posterminal

Parameterized class:

Declaring Class

Nested Class

Store

-storeld: Integer-POS list: List

+create()+login(Username,password)+find(Storeld)+getPostota is(POSid)+updateStore Totals(Id,Sales)+get(Item)

<<interface>> Store

+ getPOStota Is(POSid)+updateStore Totals(Id,Sales)+get(Item)

Pos Terminal

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.

<<bind>> (Address,24)

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.

FArray

k..k T

T.k: Integer

FArray<Point,3> AddressList

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

belowStereotype 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 façade defining the view of the work unit’s

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, association-ends, 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 boolean-

expression 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) )