“Object - oriented” means organize software as a collection of discrete objects
that ...... Corollaries 1,2 and 3 are from both axioms, whereas corollary 4 is from ...
OBJECT ORIENTED SYSTEM (CSE 601) CHAPTER 1 INTRODUCTION What is object-oriented? “Object - oriented” means organize software as a collection of discrete objects that incorporate both data structure and behavior. The general characteristics are required by an object-oriented approach include four aspects: identity, classification, polymorphism and inheritance.
Why an object orientation? •
Object-oriented methods enable to create sets of objects that work together synergistically to produce software that better model their problem domain than similar system produced by traditional techniques.
•
The systems are easier to adapt to changing requirements, easier to maintain, more robust and promote greater design and code reuse.
•
Object-oriented development allows creating modules of functionality.
•
Once objects are defined, it can be taken for granted and perform their desired functions.
Overview of Object Oriented Language Object – oriented Language is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. i.e. ¾ It uses objects, not algorithms ¾ Each object is an instance (example /case) of some class ¾ Classes are related to one another via inheritance relationship. The physical building block in these languages is called module.
1
The module is a representation of classes and objects instead of subprograms as in earlier languages.
The fundamental characteristic of object-oriented programming is that it allows the base concepts of the language to be extended to include ideas and terms closer to those of its applications. New data types can be defined in terms of existing data types until it appears that the language directly supports the primitives of the application.
Foundation of the object-oriented programming Structured design methods evolved to guide / build complex systems using algorithms as their fundamental building blocks But in object-oriented programming languages, using the class and object as basic build blocks.
Object •
The term object means a combination of data and logic that represents some real world entity.
•
In object-oriented system, everything is an object: A spreadsheet, a cell in a spreadsheet, a bar chart, a title in a bar chart, a report, a number or telephone number, a file, a folder, a printer, a word or a sentence or even a single character.
•
The objects are an abstraction which represents only those features of a thing that are deemed relevant to the current purpose and hides those features that are not relevant.
•
The example for abstraction is Map representation.
•
The Road maps concentrate on showing roads and place and omit landscape features
•
The Geological maps show rocks and other sub-surface but omit towns and roads.
•
The object has ‘state, behavior and identity’
•
State represents the particular condition that an object is in at a given moment
2
•
Behavior stands for the things that the object can do that are relevant to model.
•
Identity means that every object is unique.
•
Example: consider a person is an object, his name is identity i.e Ahmed and behavior is reading and state is studying.
Rounded boxes are used to denote particular instance of classes, class name in brackets
Classes •
• • • •
In object – oriented systems, a class is a set of objects that share a common structure and a common behavior; a single object is simply an instance of a class. A class is a specification of structure (instance variable), behavior (methods) and inheritance for objects. The classes are important mechanism for classifying objects. A method or behavior of an object is defined by its class. Each object is an instance of a class.
Meta-Types In an object-oriented system, everything is an object: numbers, arrays, records, fields, files, forms and a class is an object. In such case, class belongs to a class called a meta-
3
class or a class of classes. Meta-classes are used by the compiler. For example, the metaclasses handle messages to classes, such as constructors, “new” and “class variables”
UML META-MODEL The UML defines notations as well as a meta-model. UML graphic notations can be used not only to describe the system’s components but also to describe a model itself. This is known as a meta-model. In other words, a meta-model is a model of modeling elements. The purpose of the UML meta-model is to provide a single, common and definitive statement of the syntax and semantics of the elements of the UML. The meta-model provides us a means to connect different UML diagrams. The connection between the different diagrams is very important.
Object Oriented Methodologies The object oriented methodologies is an integrated approach to analysis, design and implementation of computer system.
The unified Approach Modeling The unified Approach (UA) is the methodology for software development proposed. The Unified Approach, based on methodogies by Booch, James rumbaugh and Jacobson. Unified Approach consists of the following concepts:
Use-case driven development Utilizing the unified modeling language for modeling Object-oriented analysis (utilizing use cases and object modeling) Repositories of reusable classes and maximum reuse. The layered approach. Incremental and development and prototyping. Continuous testing
The UML does not specify a methodology of what steps to follow to develop an application; that would be the task of the unified approach. The heart of the UA is Jacobson’s use case. The use cases are part of all other activities of the UA. Advantage of UA: In the object-oriented system is that the class tree is dynamic and can grow.
Why Modeling •
In any development project that aims at producing useful artifacts, the main focus of both analysis and design activities.
4
•
System analyst and designers produce models of systems.
•
A business analyst will start by producing a model an organization works
•
Building a model for a software system prior to its construction is as essential as having a blueprint for building a large building.
•
Good models are essential for communication among project teams.
•
As the complexity of systems increases, so does the importance of good modeling techniques.
•
The rigorous modeling language is essential for project success.
The model language must include: ¾ Model elements – fundamental modeling concepts and semantics ¾ Notation - Visual rendering of model elements ¾ Guidelines – expression of usage within the trade. The use of visual notation to represent or model a problem can provide us several benefits relating to clarity, familiarity, maintenance and simplification.
UML The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems. The UML is a standard diagramming notation or culture of software engineer. Object Modeling is the central technique in UML. It is a language independent notation: ¾ allowing the specification of classes, ¾ their data or attributes (private) and ¾ methods (public), inheritance, and ¾ other more general relationships between classes. The Unified Methods are following ¾ Booch method, ¾ OMT method(Rumbaugh), ¾ OOSE method (Jacobson)
5
UML be applied in three ways
UML as sketch
UML as blueprint
Informal and incomplete diagrams For example: Hand sketched on whiteboards
Relatively detailed design diagrams used for better understanding of existing code in UML diagrams, code generation.
UML as Programming Language Executed code will be automatically generated
6
Figure : UML as blueprint
Figure: UML as a Programming Language UML defines various types of diagrams, divided into three major categories Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. Behavior Diagrams include the Use Case Diagram, Activity Diagram, and State Machine Diagram. Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
7
Role of system analyst and designer -
System analyst will produce a more abstract model of the object in the business.
-
Designer will produce a model of how a new computerized system will work within the organization.
Need of model •
A model is quicker and easier to build.
•
A model can be used in simulations, to learn more about the thing it represents.
•
A model can represent real or imaginary things from any domain.
•
Ex: Civil engineers model bridges, economists model the effects of government policy.
Notations to describe every aspects of software development
Object Modeling Technique (OMT). The methodology consists of building a model of an application domain and then adding implementation details to it during the design of a system. This approach is called Object Modeling Technique (OMT).
Models used in Object Modeling Technique (OMT) The OMT methodology uses three types of models to describe a system:
The object Model / static Model describes the static structure of the objects in a system that change over time. This model contains object diagrams. An object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.
A static model can be viewed at a specific point in time. Static models are needed to represent the structural or static aspect of a system. For example, a customer could have more than one account.
The dynamic model: describes all aspects of a system that change over time. The dynamic model is used to specify and implement the control aspects of a system. The
8
dynamic model contains state diagrams. The state diagram is a graph whose nodes are states and whose arcs are transitions between states caused by events. A dynamic model in contrast to a static model, can be viewed as a collection of procedures or behaviors that, taken together, reflect the behavior of a system over time. Dynamic relationships show how the business objects interact to perform tasks. For example, an order interacts with inventory to determine product availability.
A system can be described by first developing its static model, which is the structure of its objects and their relationships, a base line. Then, we can examine changes to the objects and their relationships over time. Dynamic modeling is most useful during the design and implementation phase of the system development. The UML interaction diagrams and activity models are examples of UML dynamic models. The functional model: describes the data value transformations within the system. The functional model contains data flow diagrams. A data flow diagram represents a computation. A data flow diagram is a graph whose nodes are processes and whose arcs are data flows. The functional model describes computations within a system. The functional model shows how output values in a computation are derived from input values, without specifying how or when they are computed. The function model specifies the meaning of the operations in the object model and the actions in the dynamic model. Example : A spreadsheet is a kind of functional model. In most cases, the values in the spreadsheet are inconsequent and cannot be structured further. The object structure is the cells in the spreadsheet itself. The purpose of the spreadsheet is to specify values in terms
of
other
9
values.
10
Chapter 2 Object Modeling: The first step in analyzing the requirements is to construct an object model. The following steps are performed in constructing an object model: ¾ Identify objects and classes ¾ Prepare a data dictionary ¾ Identify association (including aggregations) between objects. ¾ Identify attributes of objects and links ¾ Organize and simplify object classes using inheritance ¾ Verify that access paths exist for likely queries ¾ Iterate and refine the model ¾ Group classes into modules.
Link Attributes An attribute is a property of the objects in a class. Similarly, a link attribute is a property of the links in an association. Each link attribute has a value for each link. The OMT notation for a link attribute is a box attached to the association by a loop; one or more link attributes may appear in the second region of the box.
11
Association An association describes a group of links with common structure and common semantics. Associations are inherently bidirectional. The binary association can be traversed in either direction. The direction implied is called forward direction and opposite direction is called inverse direction
12
Multiplicity
Multiplicity specifies how many instances of one class may relate to a single instance of an associated class. Multiplicity constrains the number of related objects. The most important multiplicity distinction between “one’ and “many”. One-one multiplicity
One-Many multiplicity (optional)
One-to-One Relationships These are modeled by a labeled straight line between two classes. No direction is assumed, though there may be an implicit one.
13
One-to-Many Relationship There are modeled by a labeled straight line, with a dot at the end indicating the “many” end of relationship. A number label may be used to indicate how many
14
Many-to Many Relationships These are modeled by a labeled straight line, with a dot at each end. A number label may be used to indicate how many.
Relationships among Classes • • •
Class Hierarchy, Inheritance, “is a” - Generalization / Specialization - Mammal < Monkey < Human Composition, Aggregation, “has a” - Automobile = Body + Wheels + Steering + Engine Association, a general relation between classes Employ – (works at) - Company
Generalization or inheritance Generalization refers to refining a super class into subclasses. Each subclass inherits the attributes of the super class Classes can be arranged in inheritance hierarchies. A class inherits operations and attributes from its parent. Inheritance is indicated with a triangle in the line with the apex pointing to the parent class A class inherits all the attributes and operations of its immediate parent and of its parent’s parent and so on. This is one of the underlying mechanisms to re-use code.
15
Grouping Constructs Module A module is a logical construct for grouping classes, associations and generalizations. A module captures one perspective or view of a situation. For example electrical, plumbing, and ventilation modules are different views of a building. An object model consists of one or more modules. Modules enable you to partition an object model into manageable pieces. Modules provide an intermediate unit of packaging between an entire object model and the basic building blocks of class and association. Class names and association names must be unique within a module. There is no other special notation for modules. The same class may be referenced in different modules. Referencing the same class in multiple modules is the mechanism for binding modules together. There should be fewer links between modules (external binding) than within modules (internal binding).
Sheet The complex model will not fit on a single piece of paper. A sheet is the mechanism for breaking a large object model down into a series of pages. A sheet is a single printed page. Each module consist one or more sheets. Each sheet has a title and a name or number. Each association and generalization appears on a single sheet. Classes may appear on multiple sheets. Use of sheet cross-reference circles is optional. Sheet numbers or sheet names inside circle continuous to a class box indicate other sheets that refer to a class.
Problems on object modeling In the static structure of object modeling, i.e. the structure of its objects and their relationships to each other at a single moment in time. We can’t examine changes to the objects and their relationships over time.
16
Advantages of Object Modeling The object model precedes the dynamic model and functional model because static structure is usually better defined, less dependent on application details, more stable as the solution evolves and easier for humans to understand. •
The object model describes the structure of objects in a system: their identity, their relationship to other objects, their attributes and their operations.
•
The goal in constructing an object model is to capture those concepts from the real world that are important to an application.
•
In modeling an engineering problem, the object model should contain terms familiar to engineers.
•
In modeling a business problem, terms from the business.
•
The object model is represented graphically with object diagrams containing object classes.
•
Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes.
•
Object model diagrams promote communication between computer professionals and application-domain experts.
17
Chapter 3 Analysis Stages of applying OMT Model The approach for object oriented methodology is called object Modeling Technique (OMT). The object oriented methodology consists of building a model of an application domain and then adding implementation details to it during the design of the system. There are four different stages for applying OMT model, namely • Analysis, •
System design,
•
Object Design,
•
Implementation
1. Analysis The analyst first reads the statement of the problem and then builds a model of the real world situation showing its important properties. Problem statements are generally not complete or correct. Hence the analyst must sit with the user and try to understand the problem. The analysis model describes ¾ What the desired system must do ¾ How it will be done It is important to note the following points about the analysis model It should not contain any implementation decisions such as data structures. A good model should be simple and be understood by everybody including nonprogrammers. 2. System design The system designer makes high-level decisions about the overall architecture. During the system design, the target system is divided into a number of subsystems. The following are the decisions that have to be made by the system designer
18
¾ Organize the system into sub systems ¾ Allocate subsystems to processes and tasks ¾ Choose an approach for the management of data stores ¾ Handle access to global resources ¾ Choose the implementation of control in software ¾ Handle boundary conditions. 3. Object Design The object designer builds a design model based on the analysis model but containing the implementation details. The designer adds details to the design model in accordance with the analysis model. The focus in the design model is the data structures and algorithms designed to implement each class. 4. Implementation During the implementation stage, the object classes and relationships are finally translated into a particular programming language, database or hardware implementation. The target language to be used determines the design decisions to some extent, but the design should not depend on the fine details of the programming language. During implementation, it is necessary to follow good software engineering procedures so that the system remains flexible and extensible.
Problem Analysis Problem statement The first step in developing anything is to state the requirements. The problem statement should state what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a solution. A user manual for the desired system is a good problem statement. The requestor should indicate which features are mandatory and which are optional, to avoid overly constraining design decision. The requestor should avoid describing system internals, as this restricts implementation flexibility.
19
Many problem statements, from individuals, companies and government agencies, mixture requirements with design decisions. There may sometimes be a compelling reason to require a particular computer or language. There is rarely justification to specify the use of a particular algorithm.
A problem statement may have more or less detail. A requirement for a conventional product, such as a payroll program or billing system, may have considerable detail.
Most problem statements are ambiguous, incomplete or even inconsistent. Therefore, the problem statement is just a starting point for understanding the problem, not an immutable document.
Overview of Analysis Process
Requirement Statement • • • • •
Problem Scope What is needed Application Context Assumptions Performance needs
Problem Domain The first step in analyzing the requirement is to construct an object Model. The object model describes real-world object classes and their relationship to each other. Information for the object model comes from the problem statement, expert knowledge of the application domain, and general knowledge of the real world. Identify classes and associations first, as they affect the overall structure and approach to the problem. Next add attributes to further describe the basic network of classes and associations. Then combine and organize classes using inheritance. Add operations to classes later as a by-product of constructing the dynamic and functional models. Operations modify objects and therefore cannot be fully specified until the dynamics and functionality are understood.
20
Iterations: The entire model need not be constructed uniformly. Some aspects of the problem can be analyzed in depth through several iterations while other aspects are still sketchy.
Identifying object classes The first step in constructing an object model is to identify relevant object classes from the application domain. Objects include physical entities, such as houses, employees and machines as well as concepts seating assignments and payment schedules. All classes must make sense in the application domain Discard unnecessary and incorrect classes according to the following: Redundant classes: If two classes express the same information. Ex: user and customer are redundant. Irrelevant classes: If a class has little or nothing to do with the problem, it should be eliminated. For example, but the theater ticket reservation system, the occupations of the ticket holders are irrelevant, but the occupations of the theater personnel may be relevant. Vague Classes: A class should be specific. Some tentative classes may have ill-defined boundaries or be too broad in scope. Example Stocksales, Telephone calls or Machine failure Attributes : names that primarily describe individual objects should be restated as attributes. For example, name, age, weight and address are usually attributes. Operations :if a name describes an operation that is applied to objects. For example, in a billing system for telephone calls a call would be an important class with attributes such as date, time and destination. Roles : the name of a class should reflect its intrinsic nature and not a role that it pays in an association. For example owner would be a poor name for a class in a car manufacturer’s database. The proper class is Person (or possibly customer) which assumes various different roles, such as owner, driver and lessee.
Using USE CASE Analysis The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case. A use case diagram captures the functional aspects of a system.
21
The notion of use-cases, introduced by Iver Jacobson.
One of the most fundamental problems in software engineering is determining the requirements of a system. The use-case approach requires the analyst to determine all the potential actors involved in a system. Use-cases allow us to describe at a high level the basic functionality of a system in terms of the various actors who need to interact with the system. From the use-cases, which describe broad functionality, we begin to analyze the details of the functionality of the systems we want to construct. Use-cases are broken down into sequences of actions and events. These actions and events are mapped onto objects through object interaction diagrams.
When to Use: Use Cases Diagrams Use cases are used in almost every project. The are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.
How to Draw: Use Cases Diagrams Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. Browse catalog and select items. 2. Call sales representative. 3. Supply shipping information. 4. Supply payment information. 5. Receive conformation number from salesperson.
22
These steps would generate this simple use case diagram:
Elements of a Use Case Diagram A use case diagram generally have two types of elements: one representing the business roles and the other representing the business processes
- Actor - Use Case
- Role - Processes
* System Boundary (optional) * Package (optional)
- Association •
A use case in a use case diagram is a visual representation of a distinct business functionality in a system.
•
The key term here is "distinct business functionality.“
•
To choose a business process, as the first step in identifying use cases, you should list the discrete business functions in your problem statement.
•
Each of these business functions can be classified as a potential use case.
•
Remember that identifying use cases is a discovery rather than a creation.
•
A use case is shown as an ellipse in a use case diagram
23
The name of the use case can be placed below or inside the ellipse
Use Case Associations Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case.
Actor Actors are external to the system and make use of it. An actor is typically a person, but may be a third-party organization or another computer system. One person may in fact be multiple actors, say a shop assistant may be a customer of the same shop at another time. Model actors, not individuals – For example many people can be members of a library, which can be represented by one actor called member. An actor makes use of a system in different ways.
24
Representation of Actor Three representation of an actor are equivalent.
Customer
Customer
A use-case may involve a number of actors, just as an
Individual actor may make use of several use-cases. Now it might be that the system which is being implemented in the bank needs to involve a cashier for depositing, But that to withdraw money the customer has to use the cash machine. The cashier is then an actor
25
System Boundary •
A system boundary defines the scope of what a system will be.
•
A system cannot have infinite functionality.
•
So, it follows that use cases also need to have definitive limits defined.
•
A system boundary of a use case diagram defines the limits of the system.
•
The system boundary is shown as a rectangle spanning all the use cases in the system.
•
The actors in the system are outside the system boundary.
The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case.
For large and complex systems, each of the modules may be the system boundary.
For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions.
26
The entire system can span all of these modules depicting the overall system boundary.
Packages (optional) Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams. Use packages only when diagrams become unwieldy, which generally implies they cannot be printed on a single page, to organize a large diagram into smaller ones.
27
Relationships between use cases The three types of relationships between use cases -- extends, --includes, -- and inheritance -- as well as inheritance between actors.
Extend relationships as the equivalent of a "hardware interrupt" because you don't know when or if the extending use case will be invoked (perhaps a better way to look at this is extending use cases are conditional). The Extend relationship is used when you have one use case that is similar to another use case but does a bit more. In essence it is like a subclass. Include relationships as the equivalent of a procedure call. Inheritance is applied in the same way as UML class diagrams -- to model specialization of use cases or actors in this case. The essay Reuse in Use Case Models describes these relationships.
(or)
Uses : A uses relationship between use cases is shown by a
generalization arrow from the use case. The diagram shows the use of the includes link. Both invoice purchase and online purchase include the scenarios defined by purchase valuation. In general, the includes link is to avoid repetition of scenarios in multiple use cases.
Includes
28
Generalization
Extends Search by name is said to extend search at the name extension point. The extends link is more controlled than the generalization link in that functionality can only be added at the extension points.
29
Chapter 4 Aggregation is a strong form of association in which aggregate object is made of components. Components are part of the aggregate. Aggregation relationships are modeled by a line with a diamond at the aggregate end. The dot notation, denoting many, may also be used if there are many similar parts.
Implementing Aggregation in Programming Language
Multilevel Aggregation
30
Chapter 5 Interaction diagrams •
Interaction diagrams are diagrams that describe how groups of objects collaborate to get the job done.
•
Interaction diagrams capture the behavior of a single use case showing the pattern of interaction among objects.
•
There are two kinds of interaction models: •
Sequence diagrams
•
Collaboration diagrams
Sequence Diagram •
Sequence diagram are an easy way of describing the behavior of a system by viewing the interaction between the system and its environment.
•
A sequence diagram shows an interaction arranged the time sequence.
•
It shows the objects participating in the interaction by their lifeline and the message they exchange, arranged in a time sequence.
•
A sequence diagram is made up of objects and messages.
•
Objects are represented exactly how they have been represented in all UML diagrams—as rectangles (optional: with the underlined class name within the rectangle)
Dimensions of Sequence diagram A sequence diagram has two dimensions: • The vertical dimension represents time, • The horizontal dimension represents different objects. The vertical line is called the object’s lifeline. The lifeline represents the object’s existence during the interaction. An object role is shown as a vertical dashed line, the lifeline. This form was first popularized by Jacobson. An object is shown as a box at the top of a dashed vertical line. However, sequence diagram does not show the relationship among the role or the association among the objects.
31
What is role? A role is a slot for an object within a collaboration that describes the type of object that may play the role.
Elements of a Sequence diagram Object: The primary element involved in a sequence diagram is an Object—an instance of a class. • A Sequence diagram consists of sequences of interaction among different objects over a period of time. • An object is represented by a named rectangle. • The name to the left of the ":" is the object name and to its right is the class name.
Message: The interaction between different objects in a sequence diagram is represented as messages. • A message is denoted by a directed arrow. •
Depending on the type of message, the notation differs.
•
In a Sequence diagram, you can represent simple messages, special messages to create or destroy objects, and message responses.
32
Each message is represented by an arrow between the lifeline of two objects. Each message is labeled with the message name. The label also can include the argument, control information, a message that an object sends to itself by sending the message arrow back to the same lifeline.
Figure: Transferring funds between accounts.
Advantage of using sequence diagram •
The sequence diagram is very simple and has immediate visual appeal.
•
It is an alternative way to understand the over all flow of the control of a program.
•
Instead of looking at the code and trying to find out the overall sequence of behavior, use the sequence diagram to quickly understand all sequence.
33
Collaboration Diagram •
A collaboration diagram, also called a communication diagram or interaction diagram
•
It is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML).
•
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of individual objects as well as the overall operation of the system in real time.
•
Objects are shown as rectangles with naming labels inside.
•
These labels are preceded by colons and may be underlined.
•
The relationships between the objects are shown as lines connecting the rectangles.
•
The messages between objects are shown as arrows connecting the relevant rectangles along with labels that define the message sequencing.
•
The route and seat objects are multi objects which means they are a collection of objects.
•
The message, "purchaseTicket(route, preference)” is the initializing message which is generated by the initializing actor.
•
All other messages are generated by the system between objects.
•
The initializing message is not numbered.
34
•
The first message after the initializing message is numbered.
•
Messages that are dependent on previous messages are numbered based on the number of the message they are dependent on.
•
Therefore the message, "r=findRoute(route)" is numbered "1.1" since it is dependent on the message "s=findSeat(route, preference)".
Purpose A collaboration diagram shows the objects and relationships involved in an interaction, and the sequence of messages exchanged among the objects during the interaction.
Compared with a sequence diagram A sequence diagram shows the objects and messages involved in an interaction. It shows the timing of the messages, but not the relationships among the objects.
As a decomposition diagram The collaboration diagram can be a decomposition of a class, class diagram, or part of a class diagram; It can be the decomposition of a use case, use case diagram, or part of a use case diagram.
Instance An instance in a collaboration diagram represents an instantiation of a class in a class diagram or a use case in a use case diagram.
Label [instance-name][:instance-type] instance-name is the name of the instance instance-type is a class or a use case Note: While both elements of the label are optional, you must provide one of them to avoid check errors.
35
Multi object Multi object represents a set of instances at the many end of an association.
LABLE - [name][:type] • name is the name of the multi object • type is a class or a use case
Active object An active object is an instance that owns a thread of control and can initiate control activity. For example, processes and tasks are active objects.
Collaboration diagrams are best suited to the portrayal of simple interactions among relatively small numbers of objects. As the number of objects and messages grows, a collaboration diagram can become difficult to read. The Interaction diagram loses its clarity with more complex conditional behavior. Any message path that is mutually exclusive is numbered with an "a" or "b". In finding position, if position is left then it is 1.1.1a or position is right then 1.1.1b.
36
Activity diagram State diagram vs. Activity diagram State diagram A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows.
Activity diagram An Activity diagram talks more about these transitions and activities causing the changes in the object states.
Special case of state diagram, in which sates are activities representing the performance of operations and transisitions It shows, state is the set of values that are triggered by the completion of the describes an object at a specific point in operations. time. It can be used to model an entire business It focus on the event occurring to a single process. object as it responds to message It provides a view of flows and what is going on onside a use case or among several classes. It focus on the event occurring to a single object as it responds to message
Purpose of Activity Diagram • • •
Activity diagrams can be used to model different aspects of a system Used to model business activities in an existing or potential system It May be used early in the system development lifecycle.
Activity diagrams are used for the following purpose: ¾ To model a task (in business modelling for instance); ¾ To describe a system function that is represented by a use case ¾ In operation specifications, to describe the logic of an operation Notation used in activity diagram UML diagrams are made up of four elements in activity diagram *icons • Two dimensional symbols • Paths • Strings UML diagrams are graphs – composed of various kinds of shapes, known as nodes, Joined together by lines, known as paths.
37
Both are made up of two-dimensional symbols that represent activities, linked by arrows that represent the transitions from one activity to another and the flow of control through the process that is being modeled. The start and finish of each activity graph is marked by special symbols – icons- the dot for the initial state and dot in a circle for the final state. Activity diagrams at their simplest consist of a set of activities linked together by transitions from one activity to the next. Each activity is shown as a rectangle with rounded ends. The name of the activity is written inside this two-dimensional symbol. Symbols used in Activity diagram
Symbol Description Initial Activity: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is similar to the notation used for Initial State. Activity: Represented by a rectangle with rounded (almost oval) edges.
Signal: When an activity sends or receives a message, that activity is called a signal. Signals are of two types: Input signal (Message receiving activity) shown by a concave polygon and Output signal (Message sending activity) shown by a convex polygon. Concurrent Activities: Some activities occur simultaneously or in parallel. Such activities are called concurrent activities. For example, listening to the lecturer and looking at the blackboard is a parallel activity. This is represented by a horizontal split (thick dark line) and the two concurrent activities next to each other, and the horizontal line again to show the end of the parallel activity
Final Activity: The end of the Activity diagram is shown by a bull's eye symbol, also called as a final
38
activity.
Logical database Schema In object-oriented paradigm basis for designing systems and programming code but can also be used to design databases. The OO design can design hierarchical, network, relational and object-oriented databases. The OO design are efficient, coherent, the use of a uniform design technique improves integration of database and programming language code. The most important and difficult task for many database applications is the database design. The design of the accompanying programming code is usually easier. A database design is often referred to as a data model or schema. There are two approaches to database design: attribute driven and entity driven. The attribute driven – it compiles a list of attributes relevant to the application and synthesizes groups of attributes that preserve functional dependencies. The entity driven – It discover entities that are meaningful to the application and describe them.
RDBMS Logical Data Structure A relational database logically appears as simply a collection of tables. Tables have a specific number of columns and an arbitrary number of rows. The columns of tables are called attributes and directly correspond to attributes in object model. The rows are called tuples and correspond to object instances and links. A simple value is stored at each table row and column intersection. The description of a database is called the database schema, which is specified during database design and is not expected to change frequently. Most data model has certain conventions for displaying schemas as diagrams. A displayed schema is called a schema diagram. The diagram displays the structure of each record type but not the actual instances of records. Each object in the schema such as STUDENT or COURSE – a schema construct.
39
Extended three schema architecture for object models The internal level has an internal schema, which describes the physical storage structure of the database. The internal schema uses a physical data model and describes the complete details of data storage and access paths for the database.
40
The conceptual level has a conceptual schema, which describes the structure of the whole database for a community of user. The conceptual schema hides the details of physical storage structures and concentrates on describing entities, data types, relationships, user operations and constraints. The external or view level includes a number of external schema or user view. Each external schema describes the part of the database that a particular user group is interested in and hides the rest of the database from that user group. UML CLASS DIAGRAM
Representing specialization/Generalization and Inheritance in UML class diagrams A blank triangle indicates a specialization / generalization with the disjoint constraint and a filled triangle indicates an overlapping constraint.
41
Object Model in Logical Structure of DBMS The object models focus on logical data structure. Each object model consists of many classes, associations, generalizations and attributes. Object modeling promotes deep, abstract thinking about a problem by implementation details. Object models are effective for communicating with application expert and help developers achieve a coherent, understandable, efficient and correct database design. Each table model consists of many ideal tables. These ideal tables are generic and DBMS-independent. 42
The table model decouples DBMS from object model to table model mapping rules. This improves documentation and eases porting.
Translate form object model to table To translate from an object model to ideal table, several mapping alternatives methods are used You must also supply details that are missing from object model, such as the primary key and candidate keys for each table and whether each attribute can be null. The internal schema of the three architecture consists of SQL commands that create the tables, attributes and performance tuning structures. Indexes are the most popular performance tuning device.
Mapping object classes to Tables Each class maps to one or more tables The objects in a class may be partitioned horizontally and / or vertically. Person
Object Model
Table Model
SQL Code
Person name address
Attribute name person-ID person-name address
Nulls? N N Y
CREATE TABLE Person ( person-ID ID person-name char(30) Address char(30) PRIMARY KEY (person-ID) );
Domain ID name address
not null not null
CREATE SECONDARY INDEX Person-index-name ON Person (person-name);
Mapping class to Table
43
Object Orientation v s. OORDBASE Object Orienta tion Set of conceptual, design and developm ent principles, Based on autonomous structures known as objects OO Contribution areas Programming Languages, Graphical User Interfaces, Databases, Software analysis, design, and implementation, Operating Systems OID Object ID Unique to object, assigned by system object-oriente d programming languages Smalltalk, then C++, then Java Methods Code that performs operation on object’s data and it has name and body Messages Invokes method and Sent to object Classes Collection of similar objects, Shares attributes and structure Protocol Represents object’s public aspect
Object-oriented relational Dbase Object Query Language OQL Characteristics Object Oriented Data Model: Supports complex objects Must be extensible Supports encapsulation Exhibits inheritanc e Supports object identity OODM object has behavior, inheritance, and encapsulation Handles a mix of data types Follows OO rules Follow s DBMS rules Support for complex objects Extensibility of data types
The use of Object IDs Each class derived table has an ID for the primary key; one or more object OIDs form the primary key for association-derived tables. Object –oriented languages implement identity with pointers or look-up tables into pointers. IDs provide a uniform mechanism for referencing objects. The stability of ID is particularly important for associations since they refer to objects. The main property required of an OID is that it be immutable; i.e. the OID value of a particular object should not change. Object structure: In OO databases, the state (current value) of a complex object may be constructed from other objects (or other values) by using certain type constructors. The three most basic constructors are atom, tuple (also called structured type) and set. The type constructors set, list, array and bag are called collection types or bulk types.
44
Type constructor OID
Example : A complex object
State
O1 = (i1, atom, ‘Hyderabad’) O2 = (i2, atom, ‘5’) O3 = (i3, set, {i1,i2,i3}) O4 = (i4,tuple, ) An OO dbase system provides a unique identity to each independent object stored in the dbase. This unique identity is typically implemented via a unique, system-generated object identifier or OID. The value of an OID is not visible to the external user, but it is used internally by the system to identify each object uniquely and to create and manage inter-object references. The OID can be assigned to program variables of the appropriate type when needed.
Difference between traditional dbase and oo dbase Traditional DBASE Relation models or ERR models (entity-relation model) All objects are assumed to be persistent. EMPLOYEE, represented both the type declaration for EMPLOYEE and a persistent set of all EMPLOYEE objects.
OO DBASE A class declaration of EMPLOYEE specifies only the type and operations for a class of objects. The user must separately define a persistent object of type set (EMPLOYEE) or list (EMPLOYEE) whose value is the collection of references to all persistent EMPLOYEE OBJECTS.
45
Type constructors ODL – object definition Language incorporates the preceding type constructors can be used to define the object types for a particular data bases application. The type constructor can be used to define the data structures for an OO database schema. The type constructor uses the data type as tuple, set and list. The standard data types called integer, string, float called atomic types. define type date tuple ( integer; year :
define type Department
month : integer; day:
integer; );
tuple ( dname:
string;
dnumber: integer; mgr:
tuple ( manager: Employee; startdate: Date; );
Specifying the object types employee, date and department using type constructors.
locations:
set(string);
employees: set(Employee); projects:
set(Project);
The dept of employee or projects of department – are basically references to other objects.
define type Employee: tuple
( fname:
string;
initial:
char;
Iname:
string;
eno:
string;
date of birth:
Date;
address:
string;
sex:
char;
salary:
float;
supervisor:
Employee;
dept:
Department;
);
The dept of Employee is type Department, it is used to refer to a specific department object (where the employee works). );
The attribute employees of department has its value a set of references (i.e a set of OID) to objects of type Employee these are the employees who work for the department. The inverse is the reference attribute dept of Employee.
The value of such an attribute would be an OID for a specific department object.
46
Relational Dbase
Object Dbase
Relationship among tuples are specified by attributes with matching values.
It is having relationship properties or reference attributes include OID of the related object.
These can be considered as value reference and are specified via foreign keys.
Both single references and collections of references are allowed.
Multivalued attributes are not permitted. M:N relationships must be represented not directly but as a separate relation. No built-in construct exists for inheritance. Specifying operation is not strictly required until the implementation phase.
Depending on type of access, references for an binary relationship can be declared in a single direction or both direction Inheritance are built into the model, so mapping is achieved by using the inheritance constructs such as derived (:) and EXTENDS. It is important to specify operations during the design phase. 24
Modeling workflow A development process should specify what has to be done, when it has to be done, how it should be done and by whom in order to achieve the required goal. Project management techniques are used to manage and control the process for individual projects. The Unified Software Development Process (USDP) has been developed by the team that created UML. USDP is often referred to as the Unified process. USDP does not follow the Traditional Life Cycle. But it adopts an iterative approach within four main phases namely Inception, Elaboration, Construction and Transition. USDP include: • Iterative and incremental development • Component –based development • Requirement driven development • Configurability • Architecture centrism • Visual modeling techniques. These phases reflect the different emphasis on tasks that are necessary as systems development proceeds. These differences are captured in a series of workflow that run through the development process.
47
Each workflow defines a series of activities that are to be carried out as part of workflow and specifies the roles of the people who will carry out those activities. While activity is something that has particular meaning for the developers who carry it out, a phase is considered primarily from the perspective of the project manager. The project manager thinks in terms of milestones that mark the progress of the project along its way to completion. Phases are sequential. A project passes through each phases in turn and then moves on to the next. The end of a phase is a decision point for the project management. Iteration within a phase
Project Phases Inception 1 2
Elaboration 3 4
Construction 5 6
Transition 7 8
Requirements
Analysis
Design
Implementation Test
Workflows
Size of the square relative to time spent on workflows
Phases and workflows in the Unified Software Development Process
48
When each phase is completed, those in charge must decide whether to begin the next phase or to halt development at that point. Within each phase, the workflows are essentially the same. All four phases include the full range of workflows from requirements to testing. Workflow can be seen as a flow of activities. Since each activity can be related to worker who will carry it out, it is useful for identify which workers will need to participate in the project.
Architect
Use Case
Analyse Architecture
Analyse a Use case
Engineer
Analyse a class Component Engineer Analyse a package
The analysis workflow in USDP
49
The object –oriented design process and design axioms Databases, object-oriented paradigm and logic programming are three independently developed areas in computer science. Both the logical and the object-oriented approaches to database design attracted considerable interest in the previous decades. Logic forms the basis for efficient knowledge-based systems, while object-orientated database languages are popular for their straightforward interface to applications. Axiom n [from Greek axioma, literally something worthy]. An axiom is a universally held principle generally accepted as true without proof. An example is: The shortest distance between two points is a straight line. The basic goal of the axiomatic approach is to formalize the design process and assist in establishing a scientific foundation for the object-oriented design process, to provide a fundamental basis for the creation of systems. Without scientific principles, the design field never will be systematized. •
Main focus of the analysis phase of SW development Î “what needs to be done”
•
Objects discovered during analysis serve as the framework for design
•
Class’s attributes, methods, and associations identified during analysis must be designed for implementation as a data type expressed in the implementation language
•
During the design phase, we elevate the model into logical entities, some of which might relate more to the computer domain (such as user interface, or the access layer) than the real world or the physical domain (such as people or employees). Start thinking how to actually implement the problem in a program.
•
The goal Î to design the classes that we need to implement the system.
•
Design is about producing a solution that meets the requirements that have been specified during analysis.
Analysis Vs. Design: • Analysis : o Focus on understanding the problem o Idealized design o Behavior o Functional o System structure requirements o A small model
• Design: o Focus on understanding the solution o Operations & attributes o performance o close to real code o object lifecycles 50 o non-functional requirements o a large model
OO design processes in the unified approach are as below,
Design classes, methods, attributes, & associations
Apply design axioms
Design view /access layers & prototype
Refine UML class diagrams
Continue testing
User satisfaction & usability tests based on usecases
51
¾ ¾ ¾ ¾ ¾
•
Facts and rules are axioms Ground axioms contain no variables Rules are deductive axioms Deductive axioms can be used to construct new facts from existing facts This process is known as theorem proving
An axiom = is a fundamental truth that always is observed to be valid and for which there is no counterexample or exception.
52
•
A theorem = is a proposition that may not be self-evident but can be proven from accepted axioms. Therefore, is equivalent to a law or principle. Theorem is valid if its referent axioms and deductive steps are valid.
•
A corollary = is a proposition that follows from an axiom or another proposition that has been proven
•
Suh’s design axioms to OOD :
Axiom 1 : The independence axiom. Maintain the independence of components
Axiom 2 : The information axiom. Minimize the information content of the design.
From the two design axioms, many corollaries may be derived as a direct consequence of the axioms. They even may be called design rules, and all are derived from the two basic axioms. •
Axiom 1Î states that, during the design process, as we go from requirement and use-case to a system component, each component must satisfy that requirement, without affecting other requirements
•
Axiom 2 Î concerned with simplicity. Rely on a general rule known as Occam’s razor.
Occam’s razor rule of simplicity in OO terms :
The best designs usually involve the least complex code but not necessarily the fewest number of classes or methods. Minimizing complexity should be the goal, because that produces the most easily maintained and enhanced application. In an object-oriented system, the best way to minimize complexity is to use inheritance and the system’s built-in classes and to add as little as possible to what already is there.
53
Corollary 4 Corollary 1 Axiom 1 Corollary 2 Axiom 2 Corollary 3 Corollary 6
Corollary 5
Corollaries 1,2 and 3 are from both axioms, whereas corollary 4 is from axiom 1 and corollaries 5 & 6 are from axiom 2.
54
Question bank 1. What is an object? 2. What is the main advantage of object-oriented development? 3. If you are in market to buy a washing machine, which attributes or services are relevant to you? 4. What is use-case modeling? 5. What is object modeling? 6. What is multiplicity? 7. What is UML? What is the importance of UML? 8. Name and describe the relationships in a use case diagram. 9. What is the purpose of an activity model 10. Describe the class diagram 11. What are the phases of OMT? Briefly describe each phase 12. How would you identify actors? 13. Why is use-case modeling useful in analysis 14. What is the purpose of analysis? why do we need analysis
55
Syllabus Chapter 1 : Introduction Overview of OOL; Object classes; Meta types, object oriented Methodologies, The unified Approach Modelling; Why Modelling; static and Dynamic Models; Functional Models. Chapter 2 Object modeling: object, Links, Association. Inheritance, Grouping constructs, problems on Object modeling. Advantages of Object Modeling Chapter 3 Analysis : Problem analysis, problem domain classes, identify classes and objects of real world problems. Using USE case analysis, recording analysis. Chapter 4 Basic object modeling, Multiplicity, constraints, aggregation, component. Chapter 5 Sequence diagram: modeling scenarios, mapping events to objects, interfaces, discovering attributes. Modeling simple collaboration modeling, logical database schema. Activity diagram, modeling workflow Chapter 6 Class diagram Test scenarios, interfaces. Classes, methods . stree testing. System testing. Scalability testing. Regression testing. Behavioral modeling. State chart diagram. Chapter 7 Design Architectural Design. Refining the Model. Refactoring. Coupling and Cohesion. Who should own the Attribute? Who should own the operations? Process and Threads. Chapter 8 Design classes Classes visibility; user interface. Subsystem interface. Chapter 9 Deponent Diagram Modelling Source codes. Physical Databases Chapter 10 Deployment Diagram: Modeling in a Distributed system and Embedded Systems.
56
