Vous êtes sur la page 1sur 7

OBJECT MODELLING

Object modeling is about creating a blue print of the software system that is to be constructed from objects. A good business object model gives a good, comprehensive picture of the organization.

THREE COMPONENTS OF MODELLING METHODOLOGY


1. Process: The how to steps for gathering requirements and determining the abstraction to be modeled. There are many processes out there. The one which has wider acceptance is Rational Unified Process RUP. RUP is a software development methodology that contains analysis, design, project management, and configuration & change management. 2. Notation: A graphical language to represent the model. There are many standards available for representing the model in graphical notations which are as follows OMT Object Modeling Technique (James Rumbaugh) Booch Method Grady Booch Use Case as means for finalizing Requirements - Ivar Jacobson. UML Industry Standard.

y y y y

3. Tool: A tool to help us to build the model.

OBJECT MODEL An object model in computer science is a collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. Examples, 1. The Document Object Model (DOM) is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page.

2. The Microsoft Excel object model is for controlling Microsoft Excel from another program 3. The ASCOM Telescope Driver is an object model for controlling an astronomical telescope.

Object model has a distinct second meaning of the general properties of objects in a specific computer programming language, technology, notation or methodology that uses them. For example, the Java object model, the COM object model, or the object model of OMT. Such object models are usually defined using such as class, message, inheritance, polymorphism, and encapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages. OBJECT-ROLE MODEL Object-Role Modeling (ORM) is a method for conceptual modeling and can be used as a tool for information and rules analysis. Object-Role Modeling is a fact-oriented method for performing systems analysis at the conceptual level. The quality of a database application depends critically on its design. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand. The conceptual design may include data, process and behavioral perspectives, and the actual DBMS used to implement the design might be based on one of many logical data models. (relational, hierarchic, network, object-oriented etc.)

y y

Object-Modeling Techniques
The object-modeling technique (OMT) is an object modeling language for software modeling and designing. It was developed in 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen

OBJECTIVES OF OMT y y To Develop object-oriented systems To support object-oriented programming

PURPOSES OF MODELING OMT was developed as an approach to software development.


   

testing physical entities before building them (simulation), communication with customers, visualization (alternative presentation of information), and reduction of complexity.

OMT -THREE 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 inheritances) 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 (concurrency) 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.

VARIOUS OBJECT MODELS PROJECT OBJECT MODEL y y y A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects.

Examples 1. build directory 2. source directory 3. test source directory

COMPONENT OBJECT MODEL y y y Component Object Model (COM) is a binary-interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. The term COM is used in the Microsoft software development industry as an umbrella term that encompasses the OLE,OLE Automation, ActiveX, COM+ and DCOM technologies.

BUSINESS OBJECT MODEL y y A business object model defines the business use cases from the business workers internal viewpoint. The model defines how people who work in the business, and the things they handle and use the classes and objects of the business"should relate to one another, both statically and dynamically, to produce the expected results. It has an emphasis on roles performed in the business area, and their active responsibilities. The objects of the models classes should be capable of performing all business use cases.

y y

The key elements of the business object model are:


y y y

Business workers show the set of responsibilities a person may carry. Business entities represent deliverables, resources, and events that are used or produced. Business use-case realizations show how collaborating business workers and business entities perform a workflow. The business use-case realizations are documented with:: Class diagrams that show participating business workers and business entities. Activity diagrams where swim lanes show responsibilities of business workers and object flows show how business entities are used in the workflow. Sequence diagrams that depict the details of the interaction among business workers, business actors, and how business entities are accessed, during the performance of a business use case.

y y y

THE BUSINESS OBJECT MODEL AND INFORMATION SYSTEMS In the business object model, business workers represent the roles that the employees will act whereas business entities represent those things the employees will handle. Using a business object model, you define how the employees of the business need to interact to produce the desired results for the business actor. The system use-case model and design model, on the other hand, specify the business information systems. Business modeling and system modeling address two different problem areas, at two different abstraction levels. Therefore, the general rule is that the information systems should have no direct presence in the business models. On the other hand, the employees acting as business workers use information systems to communicate with each other, and with the actors, and to access information about business entities. Whenever there is a link, association or attribute, there is also some potential information-system support.

These two modeling contexts have the following relationships:


y

y y y

An employee acting as a certain business worker corresponds to a system actor of the information system. She is probably best supported if the information systems are structured so that her entire work in a business use case is supported by one system use case. Alternatively, if the business use case is large, long-lived, or combines work from several independent areas, an information-system use case could support one operation of the business worker instead. The things the employees work withmodeled as business entitiesoften have representations in the information systems. In the object model of an information system, these business entities occur as entity classes. Associations and aggregations between business entities often give rise to corresponding association and aggregations between entity classes in the design model. Therefore, a system use case accesses and manipulates entity classes in the design model that represent the business entities accessed by the supported business use case. Finally, a business actor that directly uses a business information system also becomes a system actor of the information system.

Information Systems as Business Actors


The employees of one business contact the employees of another business through using the other business information system. From the perspective of the modeled business, that information system is a business actor. Example: A software developer tries to understand a problem in the product for which he is responsible. To understand if the problem originates from the programming tool she is using, she contacts the suppliers World Wide Web server and studies the list of known problems in the current release of the programming tool. In this way, the business worker "Software Developer" interacts with the business actor "Supplier WWW Server".

INFORMATION SYSTEMS EXPLICITLY IN THE BUSINESS OBJECT MODEL y y The general rule is that information systems should not be explicitly modeled in the business object model; they are merely tools in the hands of the business workers. Telephone banking services are good examples of this type of information system.

From the business-modeling perspective, the following approach is suggested:


y y

y y y

Regard the information system as a fully automated business worker that interacts with an actor. If the information system relates to any of the other business workers or business entities, consider illustrating this relationship with a link or an association. Perhaps the system informs a business worker of its progress, or uses information concerning a business entity. Briefly describe the business worker, as well as a list of services that represents the information system in the business object model. Model all details and characteristics of the information system and its environment in an information system model. Introduce a naming convention so that a fully automated business worker is easily identified among the business workers; for example, a prefix or a suffix, like "automated <business worker name>" or "<business worker name> (IT system)". You may even define a stereotype with a particular icon.

DIFFERENCES BETWEEN STRUCTURED AND OBJECT MODELLING

STRUCTURED MODELLING Structured modeling treats processes and data as separate components

OBJECT MODELING object-oriented modeling combines data and the process that act on the data into objects Programming functions are independent User (developer) friendly.

Programming functions are dependent Command line friendly

Vous aimerez peut-être aussi