MC0083 Spring 2013 Assignment

Master of Computer Applications Sikkim Manipal UniversityDirectorate of Distance Education

Assignment

Name :

Registration No. :

Learning Center :

Learning Center Code :

Course : MCA

Subject :MC0083 – Object Oriented Analysis & Design using UML

Semester : V Semester

Module No. : B0969

Date of submission :

Marks awarded :

Directorate of Distance EducationSikkim Manipal UniversityII Floor, Syndicate House

Manipal – 576104

____________________ ____________________ ____________________Signature of Coordinator Signature of Center Signature of Evaluator

Gaurav Singh Jantwal ROLLNUMBER


Comments by the Subject Evaluator:

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Suggestions for improvement:

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________



1. Explain the following Object Oriented Concepts with suitable examples for each:a. Objectsb. Encapsulation and information hidingc. Polymorphism

Answer 1:

a. ObjectsThe term object was first formally utilized in the Simula language. The term object means a combination of data and logic

that represents some real world entity. When developing an object-oriented application, two basic questions always rise: What objects does the application need? What functionality should those objects have?

Programming in an object-oriented system which consists of adding new kinds of objects to the system and defining how they behave.

Objects are grouped in classesA class is a set of objects that share a common structure and a common behaviour, a single object is simply an instance of a class. A class is a specification of structure (instance variables), behaviour (methods), and inheritance of objects.

Attributes: Object state and properties

Properties represent the state of an object:For example in a car object, the manufacturer could be denoted by a name, a reference to a manufacturer object, or a corporate tax identification number. In general object’s abstract state can be independent of its physical representation.

A method is a function or procedure that is defined for a class and typically can access the internal state of an object of that class to perform some operation.

Behaviour denotes the collection of methods that abstractly describes what an object is capable of doing. Each procedure defines and describes a particular behaviour of the object. The object, called the receiver, is that on which the method operates. Methods encapsulate the behaviour of the object, provide interfaces to the object, and hide any of the internal structures and states maintained by the object.

b. Encapsulation and information hidingInformation hiding is the principle of concealing the internal data and procedures of an object and providing an interface

to each object in such a way as to reveal as little as possible about its inner workings.

C++ has a very general encapsulation protection mechanism with public, private, and protected members. Public members (member data and member functions) may be accessed from anywhere. Private members are accessible one from within a class. An object data representation, such as a list or an array, usually will be private. Protected members can be accessed only from subclasses. In per-class protection, the most common form (e.g. Ada, C++, Eiffel), class methods can access any object of that class and not just the receiver. In per-object protection, methods can access only the receiver. An important factor in achieving encapsulation is the design of different classes of objects that operate using common protocol, or object’s user interface. This means that many objects will respond to the same message but each will perform the message using operations tailored to its class.

Data abstraction is the benefit of the object-oriented concept that incorporates encapsulation Sand polymorphism.

c. PolymorphismPoly means “many” and morph means “form”. In the context of object-oriented systems, polymorphism means objects

that can take on or assume many different forms.Polymorphism means that the same operation may behave differently on different classes. Polymorphism allows us to write generic, reusable code more easily, because we can specify general instructions and delegate the implementation details to the objects involved. Since no assumption is made about the class of an object that receives a message, fewer dependencies are needed in the code and, therefore maintenance is easier. For example, in a payroll system, manager, office worker, and production worker objects all will respond to the compute payroll message, but the actual operations performed are object specific.

In the UML it is assumed that if an operation is applied to an object and there are several alternative classes that have the operation defined then the object to which the operation is applied always determines the operation that is executed. This is even true if the access to the object is via a pointer in C++ using syntax like this:

pointer->function(arguments).



For example if there is a Base class with a function f ( ) and a Derived class that overrides f ( ) then an object in the Derived class will execute Derived's f, and an object in the Base class executes the Base f. This is true even if the access is via a pointer to the object and if the variable holding the pointer is declared to be of the Base type



2. Explain the following Object Oriented Methodologies:a. Rumbaugh et al.’s Object Modeling Techniqueb. The Booch Methodology

Answer 2:

a. Rumbaugh et al.’s Object Modeling Technique

The object-modeling technique (OMT) is an object modeling language for software modeling and designing. It was developed circa 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented systems, and to support object-oriented programming.

OMT was developed as an approach to software development. The purposes of modeling according to Rumbaugh (1991) are: Testing physical entities before building them (simulation), Communication with customers, Visualization (alternative presentation of information), and Reduction of complexity.

OMT has proposed three main types of models: Object model: The object model represents the static and most stable phenomena in the modeled domain. Main concepts

are classes and associations, with attributes and operations. Aggregation and generalization (with multiple inheritance) are predefined relationships.

Dynamic model: The dynamic model represents a state/transition view on the model. Main concepts are states, transitions between states, and events to trigger transitions. Actions can be modeled as occurring within states. Generalization and aggregation (concur-rency) are predefined relationships.

Functional model: The functional model handles the process perspective of the model, corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow, and actors.

OMT is a predecessor of the Unified Modeling Language (UML). Many OMT modeling elements are common to UML.

OMT OBJECT DIAGRAM

OMT STATE DIAGRAMb. The Booch Methodology



This is the broadly used method for system designing. It includes the analysis and design phase of an object oriented system. Booch method speaks both about logical and physical view of the object oriented design. Booch method uses many diagrams like the class diagrams, object diagrams, module diagrams, state transition diagrams, interaction diagrams and process diagrams. Let us now discuss some of these diagrams.

The class diagramIt gives the structure of the class using classes, the relationship between them and class utilities. Figure explains the class diagram for a fee collection system. It has two different classes that is the Student and Fees class. The Fees class inherits properties like course and other details from the Fees details class. Payment is an abstract class which has three subclasses viz., Card, Cash and Check which shows the type of payment.

The object diagramAn object diagram is a UML structural diagram that shows the instances of the classes. Figure gives the object diagram for student class. The instance of the class students has the attributes as Ram for first name, Kumar for last name and 70, 68 and 97 as scores.

The module diagramIt depicts the allocation of classes, and objects to modules in the physical design of a system.

The process diagramThis is a graphical representation of the business process flow. Figure4.8 shows the process diagram for mobile alarm system. The process starts with the ringing of the alarm. If we want to get up we switch off the alarm and then continue with the next step and the process ends; else we press the snooze button and after some time the process reoccurs.

The state transaction diagramIt is used to show the state space of a class, the action that causes the change of one state to another.



3. Describe the following UML notations:a. Diagram Elements (Graphs, Drawing paths, ...)b. Model Managementc. General Extension Mechanisms

Answer 3:

a. Diagram Elements (Graphs, Drawing paths, ...)

Graphs and Their ContentsMost 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:i. Connection (usually of lines to 2-d shapes),

ii. Containment (of symbols by 2-d shapes with boundaries), andiii. 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:i. 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.ii. 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.

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

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

Drawing PathsA path consists of a series of line segments whose endpoints coincide. The entire path is a single topological unit. Line segments may be orthogonal lines, oblique lines, or curved lines. Certain common styles of drawing lines exist: all orthogonal lines, or all straight lines, or curves only for bevels. The line style can be regarded as a tool restriction on default line input. When line segments cross, it may be difficult to know which visual piece goes with which other piece; therefore, a crossing may optionally be shown with a small semi-circular jog by one of the segments to indicate that the paths do not intersect or connect (as in an electrical circuit diagram).

In some relationships (such as aggregation and generalization) several paths of the same kind may connect to a single symbol. In some circumstances (described for the particular relationship) the line segments connected to the symbol can be combined into a single line segment, so that the path from that symbol branches into several paths in a kind of tree. This is purely a graphical presentation option; conceptually the individual paths are distinct. This presentation option may not be used when the modeling information on the segments to be combined is not identical. Invisible Hyperlinks and the Role of Tools

A notation on a piece of paper contains no hidden information. A notation on a computer screen may contain additional invisible hyperlinks that are not apparent in a static view, but that can be invoked dynamically to access some other piece of information, either in a graphical view or in a textual table. Such dynamic links are as much a part of a dynamic notation as the visible information, but this guide does not prescribe their form. We regard them as a tool responsibility. This document attempts to define a static notation for the UML, with the understanding that some useful and interesting information may show up poorly or



not at all in such a view. On the other hand, we do not know enough to specify the behavior of all dynamic tools, nor do we want to stifle innovation in new forms of dynamic presentation. Eventually some of the dynamic notations may become well enough established to standardize them, but we do not feel that we should do so now.

b. Model Management

An object database (also object-oriented database management system) is a database management system in which information is represented in the form of objects as used in object-oriented programming. Object databases are different from relational databases and belong together to the broader database management system. Object databases have been considered since the early 1980s and 1990s. Object databases main usage is in object oriented areas. When database capabilities are combined with object-oriented programming language capabilities, the result is an object-oriented database management system (OODBMS). OODBMS allow object-oriented programmers to develop the product, store them as objects, and replicate or modify existing objects to make new objects within the OODBMS. Because the database is integrated with the programming language, the programmer can maintain consistency within one environment, in that both the OODBMS and the programming language will use the same model of representation.

Relational DBMS projects, by way of contrast, maintain a clearer division between the database model and the application. As the usage of web-based technology increases with the implementation of Intranets and extranets, companies have a vested interest in OODBMS to display their complex data. Using a DBMS that has been specifically designed to store data as objects gives an advantage to those companies that are geared towards multimedia presentation or organizations that utilize computer-aided design .Object oriented development offers us a different model differing from traditional software development. So in simple words we can say that object oriented systems development is away to build software by developing objects that can be easily replaced, modified and reused. In object oriented environment, we consider software as a collection of discrete objects that encapsulate their data and functionality to shape the real world objects. Object orientation is very essential for software construction. We know that each object has attributes and methodologies.

In an object oriented system each object is responsible for itself. For example we know that every software application needs objects. For example a Microsoft windows object takes the responsibility for things like opening, sizing and closing itself. We know that a chart object is responsible for things such as maintaining its data and labels. An object oriented system emphasizes cooperative philosophy by allocating tasks among the objects for the applications. This approach is really a powerful one for us to enrich the software development process.

We can group objects into classes.

The object modelThe object model describes the structure of objects in a system: their identity, relationships to other object attributes, and operations. The object diagram contains classes interconnected by association lines. Each class represents a set of individual objects. The association lines establish relationships among the classes. Each association line represents a set of links from the objects of one class to the objects of another class.

The OMT functional modelThe OMT data flow diagram (DFD) shows the flow of data between different processes in a business. An OMT DFD provides a simple and intuitive method for describing business processes without focusing on the details of computer systems.

Data flow diagrams use four primary symbols:i. The process is any function being performed; for example, verify Password or PIN in the ATM system.

ii. The data flow shows the direction of data element movement; for example, PIN code.iii. The data store is a location where data are stored; for example, account is a data store in the ATM example.iv. An external entity is a source or destination of a data element; for example, the ATM card reader.



c. General Extension Mechanisms

Constraint and CommentSemantics: A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true; otherwise, the system described by the model is invalid (with consequences that are outside the scope of UML). Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML, others may be user-defined. A user-defined constraint is described in words in a given language, whose syntax and interpretation is a tool responsibility. A constraint represents semantic information attached to a model element, not just to a view of it.

A comment is a text string (including references to human-readable documents) attached directly to a model element. A comment can attach arbitrary textual information to any model element of presumed general importance but it has no semantic force. Comments may be used for explaining the reasons for decisions, among other things.

Notation: A constraint is shown as a text string in brackets ({ }). There is an expectation that individual tools may provide one or more languages in which formal constraints may be written. Each constraint is written in a specific language; although the language is not generally displayed on the diagram. For an element whose notation is a text string (such as an attribute, etc.), the constraint string may follow the element text string in braces. For a list of elements whose notation is a list of text strings (such as the attributes within a class), a constraint string may appear as an element in the list. The constraint applies to all succeeding elements of the list until another constraint string list element or the end of the list. A constraint attached to an individual list element does not supersede the general constraint, but may augment or modify individual constraints within the constraint string.

For a single graphical symbol (such as a class or an association path), the constraint string may be placed near the symbol, preferably near the name of the symbol, if any. For two graphical symbols (such as two classes or two associations), the constraint is shown as a dashed arrow from one element to the other element labeled by the constraint string (in braces). The direction of the arrow is relevant information within the constraint. The client (tail of the arrow) is mapped to the first position and the supplier (head of the arrow) is mapped to the second position in the constraint. For three or more graphical symbols, the constraint string is placed in a note symbol and attached to each of the symbols by a dashed line. This notation may also be used for the other cases. For three or more paths of the same kind (such as generalization paths or association paths), the constraint may be attached to a dashed line crossing all of the paths. A comment is shown as a text string (not enclosed in braces) within a note icon. Syntax for including comments within other elements (such as expressions or constraints) are not specified by UML but may be provided by a tool as part of the expression syntax for a particular language.

Example:

Mapping: A constraint string is a string enclosed in braces ({ }). The constraint string maps into the body expression in a Constraint element. The mapping depends on the language of the expression, which is known to a tool but generally not displayed on a diagram. A constraint string following a list entry maps into a Constraint attached to the element corresponding to the list entry. A constraint string represented as a stand-alone list element maps into a separate Constraint attached to each succeeding model element corresponding to subsequent list entries (until superseded by another constraint or property string).

A constraint string placed near a graphical symbol must be attached to the symbol by a hidden link by a tool operating in context. The tool must maintain the graphical linkage implicitly. The constraint string maps into a Constraint attached to the element corresponding to the symbol. A constraint string attached to a dashed arrow maps into a constraint attached to the two elements corresponding to the symbols connected by the arrow. A string enclosed in braces in a note symbol maps into a Constraint attached to the elements corresponding to the symbols connected to the note symbol by dashed lines. A string (not enclosed in braces) in a note attached to the symbol for an element maps into a Comment attached to the corresponding element.

Element Properties



Many kinds of elements have detailed properties that do not have a visual notation. In addition, users can define new element properties using the tagged value mechanism. A string may be used to display properties attached to a model element. This includes properties represented by attributes in the meta model as well as both predefined and user-defined tagged values.

Semantics: Note that we use property in a general sense to mean any value attached to a model element, including attributes, associations, and tagged values. In this sense it can include indirectly reachable values that can be found starting at a given element. Some kinds of properties would have syntax within expressions (not specified by UML) but no explicit UML notation.

A tagged value is a keyword-value pair that may be attached to any kind of model element (including diagram elements as well as semantic model elements). The keyword is called a tag. Each tag represents a particular kind of property applicable to one or many kinds of model elements. Both the tag and the value are encoded as strings. Tagged values are an extensibility mechanism of UML permitting arbitrary information to be attached to models. It is expected that most model editors will provide basic facilities for defining, displaying, and searching tagged values as strings but will not otherwise use them to extend the UML semantics. It is expected, however, that back-end tools such as code generators, report writers, and the like will read tagged values to guide their semantics inflexible ways.

Notation: A property (either a meta model attribute or a tagged value) is displayed as a command eliminated sequence of property specifications all inside a pair of braces ({ }). A property specification has the form:

name = valueWhere name is the name of a property (meta model attribute or arbitrary tag) and value is an arbitrary string that denotes its value. If the type of the property is Boolean, then the default value is true, the value is omitted. That is, to specify a value of true you may include just the keyword. To specify a value of false, you omit the name completely. Properties of other types require explicit values. The syntax for displaying the value is a tool responsibility in cases where the underlying model value is not a string or a number. Note that property strings may be used to display built-in attributes as well as tagged values.



4. What are the various classes in class stereotypes of software development process? Explain in detail.

Answer 4:

IntroductionThis section defines the UML Extension for Software Development Processes, defined in terms of the UML’s extension mechanisms, namely Stereotypes, TaggedValues, and Constraints. It describes a UML extension that has been found useful in software development processes. Although this extension was based on the Objectory process, it is general-purpose and may also be applied to other software development processes. It is not meant to be a comprehensive description of all software development processes, but is an example of one such process.

Class StereotypesAnalysis classes come in the following three kinds:

i. entityii. control

iii. boundaryDesign classes are not stereotyped in the process.

EntityEntity is a class that is passive; that is, it does not initiate interactions on its own. An entity object may participate in many different use case realizations and usually outlives any single interaction.

ControlControl is a class, an object of which denotes an entity that controls interactions between a collection of objects. A control class usually has behaviour specific for one use case and a control object usually does not outlive the use case realizations in which it participates.

BoundaryA Boundary is a class that lies on the periphery of a system, but within it. It interacts with actors outside the system as well as objects of all three kinds of analysis classes within the system.

NotationClass stereotypes can be shown with keywords in guillemets. They can also be shown with the following special icons.



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

Answer 5:

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

ii. Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models. iii. Furnish extensibility and specialization mechanisms to extend the core concepts. iv. Support specifications that are independent of particular programming languages and development processes. v. Provide a formal basis for understanding the modeling language.

vi. Encourage the growth of the object tools market. vii. Support higher-level development concepts such as components, collaborations, frameworks and patterns.

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

i. Provides guidance as to the order of a team’s activities, ii. Specifies what artifacts should be developed,

iii. Directs the tasks of individual developers and the team as a whole, and iv. 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. What are the two ways of communicating with subsystem? Explain.

Answer 6:

There are two ways of communicating with a subsystem, either by sending stimuli to the subsystem itself to be re-directed to the proper recipient inside the subsystem, or by sending stimuli directly to the recipient inside the subsystem. In the first case, an association is defined with the subsystem itself to enable stimuli sending.

A subsystem can have generalizations to other subsystems, i.e., the public and protected elements in the contents of a subsystem as well as operations and receptions are also available to its heirs.

A subsystem may offer a set of interfaces, i.e., for each operation defined in an interface, the subsystem offering the interface must have a matching operation, either as a feature of the subsystem itself or of a specification element.

Profile: Profiles can contain stereotypes, tag definitions, and constraints. They can also contain data types that are used by tag definitions for informally declaring the types of the values that can be associated with tag definitions.

Model:

Figure 7.12: Model illustration – shows Model and its environment in the metamodel by flattening the inheritance hierarchy.

A model is a description of a physical system with a certain purpose, such as to describe logical or behavioural aspects of the physical system to a certain category of readers. Examples of different kinds of models are ‘use case,’ ‘analysis,’ ‘design,’ and ‘implementation,’ or ‘computational,’ ‘engineering,’ and ‘organizational’ each representing one view of a physical system.

Thus, a model is an abstraction of a physical system. It specifies the physical system from a certain vantage point (or viewpoint); that is, for a certain category of stakeholders (for example, designers, users, or orderers of the system), and at a certain level of abstraction, both given by the purpose of the model. A model is complete in the sense that it covers the whole physical system, although only those aspects relevant to its purpose; that is, within the given level of abstraction and vantage point, are represented in the model. Furthermore, it describes the physical system only once; that is, there is no overlapping; no part of the physical system is captured more than once in a model.

A model consists of a containment hierarchy where the top-most package or subsystem represents the boundary of the physical system. This package/subsystem may be given the stereotype «topLevel» to emphasize its role within the model. It is possible to have more than one containment hierarchy within a model; that is, the model contains a set of top-most packages/subsystems each being the root of a containment hierarchy. In this case there is no single package/subsystem that represents the physical system boundary.

The model may also contain model elements describing relevant parts of the system’s environment. The environment is typically modeled by actors and their interfaces. As these are external to the physical system, they reside outside the package/subsystem hierarchy. They may be collected in a separate package, or owned directly by the model. These model elements and the model elements representing the physical system may be associated with each other.

A model may be a specialization of another model via a generalization relationship. This implies that all public and protected elements in the ancestor are also available in the specialized model under the same name and interrelated as in the ancestor.

A model may import or access another model. Models may be nested. A large physical system may be composed by a set of subordinate physical systems together making up the large physical system.


MC0083 Spring 2013 Assignment

Documents

Transcript of MC0083 Spring 2013 Assignment