OOAD - Vel Tech University

U6CSA24 OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT I OBJECT ORIENTED METHODOLGY

Object model - Elements- Class and object - Nature of object/class-Relationship among Object-Relationship among classes-Quality classes and objects - Classification-

Classical categorization - Conceptual clustering - prototype theory - Analysis and design -

Activities - Classical approaches - UML model -Introduction .

UNIT II UML NOTATIONS

Use case - usage-class diagrams - Perspectives - Association - Attributes - Operation –CRC cards-Usage -Interaction diagram-Sequence diagrams-Collaboration diagrams-Package diagrams-Concurrent state diagrams-Activity diagrams-Decomposition and activity.

UNIT III OBJECT AND RESPONSIBILTY IDENTIFICATION

OO model traditional techniques-Current techniques-Approach to identify attribute-

Service-Method.

UNIT IV BEHAVIOUR SPECIFICATIONS

Static behavior specification techniques-Control-Documenting control-Documenting static behavior - Dynamic behavior identification-Specification techniques-Documenting

Event specifications-Identifying relationships.

UNIT V UML AND PROGRAMMING

Domain model-specification model-System design-Detailed design-Coding.

REFERENCES BOOKS

1. Martin Forwler, Kendall Scott. "UML distilled-Applying the standard object modeling language", Addison Wesley, 1997.

2. Richard C lee, William M Tepfenhart, "UML and C++ - A practical guide to object oriented development", Prentice Hall, 1997.

3. Grady Booch, "Object Oriented Analysis and design with applications" II edition

Addison Wesley, 1994.

4. James martin & James J.Odell, "Object Oriented Methods-A foundation", Prentice Hall,

1997.

VEL TECH Dr. RR & Dr. SR TECHNICAL UNIVERSITY

1

UNIT I

OBJECT ORIENTED METHODOLGY

Object model

Object-oriented technology is built upon a sound engineering foundation, whose elements we collectively call the object model. The object model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence.

How you differentiate the object oriented model and traditional structured?

OOM requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture. These differences arise from the fact that structured design methods build upon structured programming, whereas object-oriented design builds upon object-oriented programming. Unfortunately, object-oriented programming means different things to different people.

Foundations of the Object Model

Object-oriented design methods have evolved to help developers exploit the expressive power of object-based and object-oriented programming languages, using the class and object as basic building blocks. Levy adds that the following events have contributed to the evolution of object-oriented concepts:

•

•

"Advances in computer architecture, including capability systems and hardware support for operating systems concepts

Advances in programming languages, as demonstrated in Simula,

•

Smalltalk, CLU, and Ada

Advances in programming methodology, including modularization and information hiding"


2

We would add to this list three more contributions to the foundation of the object model:

• Advances in database models

• Research in artificial intelligence

• Advances in philosophy and cognitive science

Elements of the Object Model

They further suggest that there are five main kinds of programming styles, here listed with the kinds of abstractions they employ:

• Procedure-oriented Algorithms

• Object-oriented Classes and objects

• Logic-oriented Goals, often expressed in a predicate calculus

• Rule-oriented If-then rules

• Constraint-oriented Invariant relationships

Rule-oriented programming would be best for the design of a knowledge base, and procedure-oriented programming would be best suited for the design of computation-intense operations. From our experience, the object-oriented style is best suited to the broadest set of applications; indeed, this programming paradigm often serves as the architectural framework in which we employ other paradigms.

Each of these styles of programming is based upon its own conceptual framework.

Each requires a different mindset, a different way of thinking about the problem. For all things object-oriented, the conceptual framework is the object model.

There are four major elements of this model:

• Abstraction

• Encapsulation

• Modularity

• Hierarchy

By major, we mean that a model without any one of these elements is not objectoriented.

There are three minor elements of the object model



Typing


3



Concurrency



Persistence

By minor, we mean that each of these elements is a useful, but not essential, part of the object Model.

Abstraction

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.List the different types of abstraction

Entity abstraction

An object that represents a useful model of a problem domain or solutiondomain entity

Action abstraction

An object that provides a generalized set of operations, all of which perform the same kind of function

Virtual machine abstraction

An object that groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.

Coincidental abstraction

An object that: packages a set of operations that have no relation to each other

Encapsulation

Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.


4

Modularity

Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.

Hierarchy

Hierarchy is a ranking or ordering of abstractions.

Typing

Typing is the enforcement Of the class of an object, such, that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways.

Concurrency

Concurrency is tbe properly that distinguisbes an active object from one tbat is not active.

Persistence

Persistence is theproperty of an object tbrougb which its existence transcends time (i.e. tbe object continues to exist after its creator ceases to exist) and/or space (i. e. the objects location moves from the address space in wbich it was created).

The Nature of an Object

An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable.

The state of an object encompasses all of the (usually static) properties of tbe object plus tbe current(usually dynamic) values of each of these properties.


5

The Meaning of Behavior No object exists in isolation. Rather, objects are acted upon, and themselves act upon other objects. Thus, we may say that Behavior is how an object acts and reacts, in terms of its state changes and message passing.

“Identity is that property of an object which distinguishes it from all other objects "

Relationships Among Objects

The relationship between any two objects encompasses the assumptions that each makes about the other, including what operations can be performed and what behavior results. We have found that two kinds of object hierarchies are of particular interest in object-oriented analysis and design, namely:

• Links

• Aggregation

Figure Link

Link is a "physical or conceptual connection between objects". An object collaborates with other objects through its links to these objects.


6

A line between two object icons represents the existence of a link between the two and means that messages may pass along this path. Messages are shown as directed lines epresenting the direction of the message, with a label naming the message itself. For example, here we see that the object aController has links to two instances of DisplayItem (the objects a and b). Although both a and b probably have links to the view in which they are shown, we have chosen to highlight only once such link,from a to aView. Only across these links may one object send messages to another.

As a participant in a link, an object may play one of three roles:

• Actor An object that can operate upon other objects but is never operated upon by other objects; in some contexts, the terms active object and actor are interchangeable

• Server An object that never operates upon other objects; it is only operated upon by other objects

• Agent An object that can both operate upon other objects and be operated upon by other objects; an agent is usually created to do some work on behalf of an actor or another agent

The Nature of a Class

A class is a set of objects that share a common structure and a common behavior.

The concepts of a class and an object are tightly interwoven, for we cannot talk about an object without regard for its class. However, there are imiportant differences between these two terms. Whereas an object is a concrete entity that exists in time and space, a class represents only an abstraction, the “essence" of an object, as it were. Thus, we may speak of the class Mammal, which represents the characteristics common to all mammals. To identify a particular mammal in this class, we must speak of "this mammal” or "that mammal."

The interface of a class provides its outside view and therefore emphasizes the abstraction while hiding its structure and the secrets of its behavior. This interface primarily consists of the declarations of all the operations applicable to


7

instances of this class, but it may also include the declaration of other classes, constants, variables, and exceptions as needed to complete the abstraction. By contrast, the implementation of a class is its inside view, which encompasses the secrets of its behavior. The implementation of a class primarily consists of the implementation of all of the operations defined in the interface of the class.

We can further divide the interface of a class into three parts:

• Public A declaration that is accessible to all clients

• Protected A declaration that is accessible only to the class itself, its subclasses, and its friends

• Private A declaration that is accessible only to the class itself and its friends

Relationships Among Classes

Kinds of Relationships

Consider for a moment the similarities and differences among the following classes of objects: flowers, daisies, red roses, yellow roses, petals, and ladybugs. We can make the following observations:

• A daisy is a kind of flower.

• A rose is a (different) kind of flower.

• Red roses and yellow roses are both kinds of roses.

• A petal is a part of both kinds of flowers.

• Ladybugs eat certain pests such as aphids, which may be infesting certain kinds of flowers.

From this simple example we conclude that classes, like objects, do not exist in isolation. Rather, for a particular problem domain, the key abstractions are usually related in a variety of interesting ways, forming the class structure of our design.We establish relationships between two classes for one of two reasons. First, a class relationship might indicate some sort of sharing. For example, daisies and roses are both kinds of flowers, meaning that both have brightly colored petals, both emit a fragrance, and so on. Second, a class relationship might indicate some kind of semantic connection. Thus, we say that red roses and yellow roses are more alike than are daisies and roses, and daisies and roses are more closely related than are petals and flowers. Similarly, there is a symbiotic connection between ladybugs and


8

flowers: ladybugs protect flowers from certain pests, which in tum serve as a food source for the ladybug.

In all, there are three basic kinds of class relationships. The first of these is generalization/specialization, denoting an "is a" relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower. The second is whole/part, which denotes a "part of" relationship. Thus, a petal is not a kind of a flower; it is a part of a flower. The third is association, which denotes some semantic dependency among otherwise unrelated classes, such as between ladybugs and flowers. As another example, roses and candles are largely independent classes, but they both represent things that we might use to decorate a dinner table.

Several common approaches have evolved in programming languages to capture generalization/specialization, whole/part, and association relationships.

Specifically, most object-oriented languages provide direct support for some combination of the following relationships:

• Association

• Inheritance

• Aggregation

• Using

• Instantiation

• Metaclass

Of these six different kinds of class relationships, associations are the most general but also the most semantically weak. Inheritance is perhaps the most semantically interesting of these concrete relationships, and exists to express generalization/specialization relationships. In our experience, however, inheritance is an insufficient means of expressing all of the rich relationships that may exist among the key abstractions in a given problem domain. We also need aggregation relationships, which provide the whole/part relationships manifested in the class's instances. Additionally, we need using relationships, which establish the links among the class's instances

Association


9

we may show a simple association between these two classes: the class Product denotes the products sold as part of a sale, and the class Sale denotes the transaction through which several products were last sold. By implication, this association suggests bidirectional navigation: given an instance of Product, we should be able to locate the object denoting its sale, and given an instance of Sale, we should be able to locate all the products sold during the transaction.

Semantic Dependencies

An association only denotes a semantic dependency and does not state the direction of this dependency (unless otherwise stated, an association implies bidirectional navigation, as in our example), nor does it state the exact way in which one class relates to another (we can only imply these semantics by naming the role each class plays in relationship with the other). However, these semantics are sufficient during the analysis of a problem, at which time we need only to identily such dependencies. Through the creation of associations, we come to capture the participants in a semantic relationship, their roles, and, as we will discuss, their cardinality.

Cardinality Our example introduced a one-to-many association, meaning that for each instance of the class Sale, there are zero or more instances of the class Product, and for each product, there is exactly one sale. This multiplicity denotes the cardinality of the association.

In practice, there are three common kinds of cardinality across an association:



One-to-one



One-to-many



Many-to-many

Inheritance


10

A subclass may inherit the structure and behavior of its superdass.

Quality Classes and Objects

"A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework"

We suggest five meaningful metrics:

• Coupling

• Cohesion

• Sufficiency

• Completeness

Message passing may thus take one of the following forms:

• Synchronous An operation commences only when the sender has initiated the action and the receiver is ready to accept the message; the sender and receiver will wait indefinitely until both parties are ready to proceed.

• Balking The same as synchronous, except that the sender will abandon the operation if the receiver is not immediately ready.

• Timeout The same as synchronous, except that the sender will only wait for a specified amount of time for the receiver to be ready.

• Asynchronous A sender may initiate an action regardless of whether the receiver is expecting the message.

CLASSIFICATION

In object-oriented design, recognizing the sameness among things allows us to expose the commonality within key abstractions and mechanisms, and eventually leads us to smaller and simpler architectures


11

1. The Importance of Proper Classification

Classification and Object-Oriented Development

 The identification of classes and objects is the hardest part of object-oriented analysis and design.



Our experience shows that identification involve both discovery and invention.



Through discovery, we come to recognize the key abstractions and mechanisms that form the vocabulary of our problem domain.



Through invention, we devise generalized abstractions as well as new mechanisms that specify how objects collaborate.



Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of

 finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior.



Intelligent classification is actually a part of all good science.



As Michalski and Step observe, "An omnipresent problem in science is to construct meaningful classifications of observed objects or situations.



Such classifications facilitate human comprehension of the observations and the subsequent development of a scientific theory" .



In the domain of building architecture and city planning, Alexander notes that, for the architect, "his act of design, whether humble, or gigantically complex, is governed entirely by the patterns he has in his mind at that moment, and his ability to combine these patterns to form a new design" .



Classification helps us to identify generalization, specialization, and aggregation hierarchies among classes.



By recognizing the common pattems of interaction among objects, we come to invent the mechanisms that serve as the soul of our implementation.



Classification also guides us in making decisions about modularization.


12



We may choose to place certain classes and objects together in the same module or in different modules, depending upon the sameness we find among these declarations; coupling and cohesion are simply measures of this sameness.



Classification also plays a role in allocating processes to processors.



We place certain processes together in the same processor or different processors, depending upon packaging, performance, or reliability concerns.

1.The Incremental and lterative Nature of Classification:-



The intelligent classification is intellectually hard work, and that it best comes about through an incremental and iterative process.



This incremental and iterative nature is evident in the development of such diverse software Technologies as graphical user interfaces, database standards, and even fourth-generation languages.



As Shaw has observed in software engineering, "The development of individual abstractions often follows a common pattern. First, problems are solved ad hoc.



As experience accumulates, some solutions turn out to work better than others, and a sort of folklore is passed informally from person to person.



Eventually, the useful solutions are understood more systematically, and they are codified and analyzed.



This enables the development of models that support automatic implementation and theories that allow the generalization of the solution.



This in turn enables a more sophisticated level of practice and allows us to tackle harder problems - which we often approach ad hoc, starting the cycle over again"


13

2. Identifying Classes and Objects

Classical and Modern Approaches



The problem of classification has been the concern of countless philosophers, linguists, cognitive scientists, and mathematicians, even since before the time of Plato.



It is reasonable to study their experiences and apply what we learn to objectoriented design.



Historically, there have only been three general approaches to classification:

• Classical categorization

• Conceptual clustering

• Prototype theory a) Classical Categorization :-

In the classical approach to categorization, "All the entities that have a given property or collection of properties in common form a category.

Such properties are necessary and sufficient to define the category".

For example, married people constitute a category: one is either married or not, and the value of this property is sufficient to decide to which group a particular person belongs.

On the other hand, tall people do not form a category, unless we can agree to some absolute criteria for what distinguishes the property of tall from short.

The classical approach to categorization is also reflected in modern theories of child development.

Piaget observed that around the age of one, a child typically develops the concept of


14

object permanence; shortly thereafter, the child acquires skills in classifying these objects, first using basic categories such as dogs, cats, and toys . b)Conceptual Clustering :-



Conceptual clustering is a more modern variation of the classical approach, and largely derives from attempts to explain how knowledge is represented.



As Stepp and Michalski state, "In this approach, classes (clusters of entities) are generated by first formulating conceptual descriptions of these classes and then classifying the entities according to the descriptions" .



For example, we may state a concept such as "a love song."



This is a concept more than a property, for the "love songness" of any song is not something that may be measured empirically.



However, if we decide that a certain song is more of a love song than not, we place it in this category. Thus, conceptual clustering represents more of a probabilistic clustering of objects.



Conceptual clustering is closely related to fuzzy (multivalue) set theory, in which objects may belong to one or more groups, in varying degrees of fitness.



Conceptual clustering makes absolute judgments of classification by focusing upon the "best fit." c) Prototype Theory:-

Classical categorization and conceptual clustering are sufficiently expressive to account for most of the classifications we ever need in the design of complex software systems.

However, there are still some situations in which these approaches are inadequate.

This leads us to the more recent approach to classification, called prototype theory,


15

which derives primarily from the work of Rosch and her colleagues in the field of cognitive psychology .

Object-Oriented Analysis

The boundaries between analysis and design are fuzzy, although the focus of each is quite distinct.

In analysis, we seek to model the world by discovering the classes and objects that form the vocabulary of the problem domain, and in design, we invent the abstractions and mechanisms that provide the behavior that this model requires i) Classical Approaches:-

A number of methodologists have proposed various sources of classes and objects, derived from the requirements of the problem domain.

We call these approaches classical because they derive primarily from the principles of classical categorization.

For example, Shlaer and Mellor suegest that candidate classes and objects usually come from one of the following sources :


16

Behavior Analysis:-

Whereas these classical approaches focus upon tangible things in the problem domain, another school of thought in object-oriented analysis focuses upon dynamic behavior as the primary source of classes and objects.

These approaches are more akin to conceptual clustering: we form classes based upon groups of objects that exhibit similar behavior.

"The knowledge an object maintains and the actions an object can perform.

Responsibilities are meant to convey a sense of the purpose of an object and its place in the system.


17

The responsibilities of an object are all the services it provides for all of the contracts it supports".

In this manner, we group things that have common responsibilities, and form hierarchies of classes involving superclasses that embody general responsibilities and subclasses that specialize their behavior.

Domain Analysis :-

The principles we have dis'cussed thus far are typically applied to the development of single, specific applications.

Domain analysis, on the other hand, seeks to identify the classes and objects that are common to all applications within a given domain, such as patient record tracking, bond trading, compilers, or missile avionics systems.

If you are in the midst of a design and stuck for ideas as to the key abstractions that exist, a narrow domain analysis can help by pointing you to the key abstractions that have proven useful in other related systems.

Domain analysis works well because, except for special situations, there are very few truly unique kinds of software systems.

The idea of domain analysis was first suggested by Neighbors. We define domain analysis as “an attempt to identify the objects, operations, and relationships that domain experts perceive to be important about the domain" .

Moore and Bailin suggest the following steps in domain analysis:

• "Construct a strawman generic model of the domain by consulting with domain experts.

• Examine existing systems within the domain and represent this understanding in a common format.

• Identify similarities and differences between the systems by consulting with domain experts.

• Refine the generic model to accommodate existing systems"

.


18

Use-Case Analysis:-



In isolation, the practices of classical analysis, behavior analysis, and domain analysis all depend upon a large measure of personal experience on the part of the analyst.

 For the majority of development projects, this is unacceptable, because such a process is neither deterministic nor predictably successful.

Key Abstractions and Mechanisms

Identifying Key Abstractions

Finding Key Abstractions :-

A key abstraction is a class or object that forms part of the vocabulary of the problem domain.

The primary value of identifying such abstractions is that they give boundaries to our problem; they highlight the things that are in the system and therefore relevant to our design, and suppress the things that are outside the system and therefore superfluous.

The identification of key abstractions is highly domain-specific.

The identification of key abstractions involves two processes: Discovery and

Invention.

Discovery- we come to recognize the abstractions used by domain experts; if the domain expert talks about it, then the abstraction is usually important

Invention - we create new classes and objects that are not necessarily part of the problem domain, but are useful artifacts in the design or implementation.


19

Refining Key Abstractions :-

Once we identify a certain key abstraction as a candidate, we must evaluate it according to the metrics described in the previous chapter.

As Stroustrup suggests, "Often this means that the programmer must focus on the questions:



How are objects of this class created?



Can objects of this class be copied and/or destroyed?



What operations can be done on such objects?



If there are no good answers to such questions, the concept probably wasn't

'clean' in the first place, and it might be a good idea to think a bit more about the problem and the proposed solution instead of immediately starting to

'code around' the problems

We offer the following suggestions: o Objects should be named with proper noun phrases, such as theSensor or just simply

shape. o Classes should be named with common noun phrases, such as Sensors or

Shapes. o Modifier operations should be named with active verb phrases, such as draw or moveLeft. o Selector operations should imply a query or be named with verbs the form "to be," such as extentOf or is0pen. o The use of underscores and styles of capitalization are largely matters of personal taste. o No matter which cosmetic style you use, at least have your programs be selfconsistent.


20

Identifying Mechanisms

Finding Mechanisms :-

The term mechanism to describe any structure whereby objects collaborate to provide some behavior that satisfies a requirement of the problem.

Whereas the design of a class embodies the knowledge of how individual objects behave, a mechanism is a design decision about how collections of objects cooperate.

Mechanisms thus represent patterns of behavior. o A mechanical linkage from the accelerator to the carburetor (the most common mechanism). o An electronic linkage from a pressure sensor below the accelerator to a computer that controls the carburetor (a drive-by-wire mechanism). o No linkage exists; the gas tank is placed on the roof of the car, and gravity causes fuel to flow to the engine. Its rate of flow is regulated by a clip around the fuel line; pushing on the accelerator pedal eases tension on the clip, causing the fuel to flow faster (a low-cost mechanism).

Categorization

Categorization is the process in which ideas and objects are recognized, differentiated and understood [1] . Categorization implies that objects are grouped into categories, usually for some specific purpose. Ideally, a category illuminates a relationship between the subjects and objects of knowledge. Categorization is fundamental in language, prediction, inference, decision making and in all kinds of environmental interaction. It is indicated that categorization plays a major role in programming [2] .

There are many categorization theories and techniques. In a broader historical view, however, three general approaches to categorization may be identified:


21







Classical categorization

Conceptual clustering

Prototype theory

The classical view

Classical categorization comes to us first from Plato, who, in his Statesman dialogue, introduces the approach of grouping objects based on their similar properties. This approach was further explored and systematized by Aristotle in his

Categories treatise, where he analyzes the differences between classes and objects.

Aristotle also applied intensively the classical categorization scheme in his approach to the classification of living beings (which uses the technique of applying successive narrowing questions such as "Is it an animal or vegetable?", "How many feet does it have?", "Does it have fur or feathers?", "Can it fly?"...), establishing this way the basis for natural taxonomy.

The classical Aristotelian view claims that categories are discrete entities characterized by a set of properties which are shared by their members. In analytic philosophy, these properties are assumed to establish the conditions which are both necessary and sufficient conditions to capture meaning.

According to the classical view, categories should be clearly defined, mutually exclusive and collectively exhaustive. This way, any entity of the given classification universe belongs unequivocally to one, and only one, of the proposed categories.

Conceptual clustering

Conceptual clustering is a modern variation of the classical approach, and derives from attempts to explain how knowledge is represented. In this approach, classes (clusters or entities) are generated by first formulating their conceptual descriptions and then classifying the entities according to the descriptions.

Conceptual clustering developed mainly during the 1980s, as a machine paradigm for unsupervised learning. It is distinguished from ordinary data clustering by generating a concept description for each generated category.


22

Categorization tasks in which category labels are provided to the learner for certain objects are referred to as supervised classification, supervised learning, or concept learning. Categorization tasks in which no labels are supplied are referred to as unsupervised classification, unsupervised learning, or data clustering. The task of supervised classification involves extracting information from the labeled examples that allows accurate prediction of class labels of future examples. This may involve the abstraction of a rule or concept relating observed object features to category labels, or it may not involve abstraction (e.g., exemplar models). The task of clustering involves recognizing inherent structure in a data set and grouping objects together by similarity into classes. It is thus a process of generating a classification structure.

Conceptual clustering is closely related to fuzzy set theory, in which objects may belong to one or more groups, in varying degrees of fitness.

Prototype Theory

Since the research by Eleanor Rosch and George Lakoff in the 1970s, categorization can also be viewed as the process of grouping things based on prototypes - the idea of necessary and sufficient conditions is almost never met in categories of naturally occurring things. It has also been suggested that categorization based on prototypes is the basis for human development, and that this learning relies on learning about the world via embodiment.

A cognitive approach accepts that natural categories are graded (they tend to be fuzzy at their boundaries) and inconsistent in the status of their constituent members.

Systems of categories are not objectively "out there" in the world but are rooted in people's experience. Conceptual categories are not identical for different cultures, or indeed, for every individual in the same culture.

Categories form part of a hierarchical structure when applied to such subjects as taxonomy in biological classification: higher level: life-form level, middle level: generic or genus level, and lower level: the species level. These can be distinguished by certain traits that put an item in its distinctive category. But even these can be arbitrary and are subject to revision.


23

Categories at the middle level are perceptually and conceptually the more salient.

The generic level of a category tends to elicit the most responses and richest images and seems to be the psychologically basic level. Typical taxonomies in zoology for example exhibit categorization at the embodied level, with similarities leading to formulation of "higher" categories, and differences leading to differentiation within categories.

UML Introduction

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group. It was first added to the list of OMG adopted technologies in 1997, and has since become the industry standard for modeling software-intensive systems.

[1]

UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems.

1.

used for both database and software modeling

2.

version 1.1 was adopted in November 1997 by the Object Management Group

(OMG) as a standard language for object-oriented analysis and design

3.

Initially based on a combination of the Booch, OMT (Object Modeling

Technique) and OOSE (Object-Oriented Software Engineering) methods,

UML was refined and extended by a consortium of several companies, and is







 undergoing minor revisions by the OMG Revision Task Force.

4.

Ivar Jacobson is known as the father of Use Cases.

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development.

[2] UML offers a standard way to visualize a system's architectural blueprints, including elements such as: activities actors business processes database schemas


24







(logical) components programming language statements reusable software components.

[3]

UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.

[4] UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language.

[citation needed] UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, [citation needed] and is evolving under the auspices of the Object Management

Group (OMG).

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

1 The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the

UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

1.

Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.

2.

Provide extensibility and specialization mechanisms to extend the core concepts.

3.

Be independent of particular programming languages and development processes.

4.

Provide a formal basis for understanding the modeling language.


25

5.

Encourage the growth of the OO tools market.

6.

Support higher-level development concepts such as collaborations, frameworks, patterns and components.

7.

Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale.

In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified

Modeling Language (UML) was designed to respond to these needs.

Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction.

UML diagrams commonly created in visual modeling tools include: 1

Use Case Diagram displays the relationship among actors and use cases.

1

Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. 1

Interaction Diagrams

 Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).

1

 Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.

1


26

State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.

1

Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

1

Physical Diagrams

 Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some

 components exist at compile time, at link time, at run times well as at more than one time.

1

Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.

1

The UML process

There are four kinds of things in the UML.

1. Structural Things.

2. Behavioral Things.

3. Grouping Things.

4. Annotational Things.


27

Advantages of UML

 You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML.

 Used for modeling middleware

 Built upon the MOF™ metamodel for OO modeling

 UML Profiles (that is, subsets of UML tailored for specific purposes) help you model Transactional, Real-time, and Fault-Tolerant systems in a natural way.

 UML is effective for modeling large, complex software

 systems

 • It is simple to learn for most developers, but provides

 advanced features for expert analysts, designers and architects

 • It can specify systems in an implementation-independent manner

 • 10-20% of the constructs are used 80-90% of the time

 • Structural modeling specifies a skeleton that can be refined

 and extended with additional structure and behavior

 • Use case modeling specifies the functional requirements of

 system in an object-oriented manner


28

UNIT II

UML NOTATIONS

Use Case

As UML describes the real time systems it is very important to make a conceptual model and then proceed gradually. Conceptual model of UML can be mastered by learning the following three major elements:

 UML building blocks

 Rules to connect the building blocks

 Common mechanisms of UML

The building blocks of UML can be defined as:

 Things

 Relationships

 Diagrams

(1) Things:

Things are the most important building blocks of UML. Things can be:

 Structural

 Behavioral

 Grouping

 Annotational

Structural things:

The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.


29

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:


30

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one

Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.


31

(2) Relationship :

Relationship is another most important building block of UML. It shows how elements are associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the other one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected.

One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.


32

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it a complete one.

UML includes the following nine diagrams and the details are described in the following chapters.

1.

Class diagram

2.

Object diagram

3.

Use case diagram

4.

Sequence diagram

5.

Collaboration diagram

6.

Activity diagram

7.

Statechart diagram

8.

Deployment diagram

9.

Component diagram

UML Architecture

Any real world system is used by different users. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewer.s perspective. The better we understand the better we make the system.

UML plays an important role in defining different perspectives of a system. These perspectives are:


33

 Design

 Implementation

 Process

 Deployment

And the centre is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case.

 Design of a system consists of classes, interfaces and collaboration. UML

 provides class diagram, object diagram to support this.

Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support

 implementation perspective.

Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective.

 Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective.

Association:

 Association defines the relationship between two or more classes in the

System. These generally relates to the one object having instance or reference of another object inside it. This article discusses on how we can implement

Association in UML.

Associations in UML can be implemented using following ways: 1) Multiplicity 2)

Aggregation 3) Composition

 Multiplicity in UML: Multiplicity indicates the no of instance of one class is linked to one instance of another class. The various multiplicity values are listed below:


34

Association Notation:

Association describes how the elements in an UML diagram are associated. In simple word it describes how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two associated elements as shown below. The multiplicity is also mentioned at the ends (1, * etc) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Qualified Associations

A qualified association is the UML equivalent of a programming concept variously known as associative arrays, maps, and dictionaries.

Figure shows a way of representing the association between the Order and Order

Line classes that uses a qualifier. The qualifier says that in connection with an Order, there may be one Order Line for each instance of Product.


35

Figure Qualified Association

Conceptually, this example indicates that you cannot have two Order Lines within an Order for the same Product. From a specification perspective, this qualified association would imply an interface along the lines of

class Order {

public OrderLine getLineItem

(Product aProduct);

public void addLineItem

(Number amount, Product forProduct);

Thus, all access to a given Line Item requires a Product as an argument. A multiplicity of 1 would indicate that there must be a Line Item for every Product; * would indicate that you can have multiple Order Lines per Product but that access to the Line Items is still indexed by Product.

From an implementation perspective, this suggests the use of an associative array or similar data structure to hold the order lines.

Class Order {

private Map _lineItems;

In conceptual modeling, I use the qualifier construct only to show constraints along the lines of "single Order Line per Product on Order." In specification models, I use it


36

to show a keyed lookup interface. I'm quite happy to use both this and an unqualified association at the same time if that is a suitable interface.

I use qualifiers within implementation models to show uses of a map, dictionary, associative array, or similar data structure.

Association Class

Association classes allow you to add attributes, operations, and other features to associations, as shown in Figure .

Figure. Association Class

We can see from the diagram that a Person may work for a single Company. We need to keep information about the period of time that each employee works for each Company.

We can do this by adding a dateRange attribute to the association. We could add this attribute to the Person class, but it is really a fact about a Person's relationship to a

Company, which will change should the person's employer change.


37

Figure shows another way to represent this information: make Employment a full class in its own right. (Note how the multiplicities have been moved accordingly.) In this case, each of the classes in the original association has a single-valued association end with regard to the Employment class. The "employer" end now is derived, although you don't have to show this.

Figure . Promoting an Association Class to a Full Class

What benefit do you gain with the association class to offset the extra notation you have to remember? The association class adds an extra constraint, in that there can be only one instance of the association class between any two participating objects. I feel the need for an example.

Take a look at the two diagrams in Figure. These diagrams have much the same form. However, we could imagine a Person working for the same Company at different periods of time-that is, he or she leaves and later returns. This means that a

Person could have more than one Employment association with the same Company over time. With regard to the Person and Skill classes, it would be hard to see why a

Person would have more than one Competency in the same Skill; indeed, you would probably consider that an error.


38

Figure. Association Class Subtleties

In the UML, only the latter case is legal. You can have only one Competency for each combination of Person and Skill.

In the past, modelers made various assumptions about the meaning of an association class in these circumstances. Some assumed that you can have only unique combinations, such as competency, whereas others did not assume such a constraint.

Many people did not think about it at all and may have assumed the constraint in some places and not in others. So when using the UML, remember that the constraint is always there.

You often find this kind of construct with historical information, such as in the preceding Employment case. A useful pattern here is the Historic Mapping pattern described in Fowler (1997). We can use this by defining a «history» stereotype (see

Figure 6-17).


39

Figure. History Stereotype for Associations

The model indicates that a Person may work for only a single Company at one time.

Over time, however, a Person may work for several Companies. This suggests an interface along the lines of

class Person {

//get current employer

Company getEmployer();

//employer at a given date

Company getEmployer(Date);

void changeEmployer(Company newEmployer,

Date changeDate);

void leaveEmployer (Date changeDate);

The «history» stereotype is not part of the UML, but I mention it here for two reasons. First, it is a notion I have found useful on several occasions in my modeling career. Second, it shows how you can use stereotypes to extend the UML.

Attributes

A logical data value of an object In UML:

Attributes are shown in the second compartment of the class box. The type of an attribute may optionally be shown


40

In a domain model, attributes and data types should be simple. Complex concepts should be represented by an association to another conceptual class.

UML Standard Diagrams

The elements are like components which can be associated in different ways to make a complete UML pictures which is known as diagram. So it is very important to understand the different diagrams to implement the knowledge in real life systems.

Any complex system is best understood by making some kind of diagrams or pictures. These diagrams have a better impact on our understanding. So if we look around then we will realize that the diagrams are not a new concept but it is used widely in different form in different industries.

We prepare UML diagrams to understand a system in better and simple way. A single diagram is not enough to cover all aspects of the system. So UML defines various kinds of diagrams to cover most of the aspects of a system.

You can also create your own set of diagrams to meet your requirements. Diagrams are generally made in an incremental and iterative way.

There are two broad caetgories of diagrams and then are again divided into subcategories:

 Structural Diagrams

 Behavioral Diagrams


41

Structural Diagrams:

The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable.

These static parts are represents by classes, interfaces, objects, components and nodes. The four structural diagrams are:

 Class diagram

 Object diagram

 Component diagram

 Deployment diagram

Class Diagram:

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes, interfaces, associations and collaboration.

Class diagrams basically represent the object oriented view of a system which is static in nature.

Active class is used in a class diagram to represent the concurrency of the system.

Class diagram represents the object orientation of a system. So it is generally used for development purpose. This is the most widely used diagram at the time of system construction.

Object Diagram:

Object diagrams can be described as an instance of class diagram. So these diagrams are more close to real life scenarios where we implement a system.

Object diagrams are a set of objects and their relationships just like class diagrams and also represent the static view of the system.


42

The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective.

Component Diagram:

Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces or collaborations. So Component diagrams represent the implementation view of a system. During design phase software artifacts (classes, interfaces etc) of a system are arranged in different groups depending upon their relationship. Now these groups are known as components.

Finally, component diagrams are used to visualize the implementation.

Deployment Diagram:

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed.

Deployment diagrams are used for visualizing deployment view of a system. This is generally used by the deployment team.

Behavioral Diagrams:

Any system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams:

 Use case diagram

 Sequence diagram

 Collaboration diagram

 Statechart diagram

 Activity diagram


43

Use case Diagram:

Use case diagrams are a set of use cases, actors and their relationships. They represent the use case view of a system. A use case represents a particular functionality of a system.

So use case diagram is used to describe the relationships among the functionalities and their internal/external controllers. These controllers are known as actors

Sequence Diagram:

A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from one object to another.

Interaction among the components of a system is very important from implementation and execution perspective.

So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality.

Collaboration Diagram:

Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links.

The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.

Statechart Diagram:

Any real time system is expected to be reacted by some kind of internal/external events. These events are responsible for state change of the system.


44

Statechart diagram is used to represent the event driven state change of a system. It basically describes the state change of a class, interface etc.

State chart diagram is used to visualize the reaction of a system by internal/external factors.

Activity Diagram:

Activity diagram describes the flow of control in a system. So it consists of activities and links. The flow can be sequential, concurrent or branched.

Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to capture the entire flow in a system.

Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea of how the system will work when executed.

Definition for UML Notation

UML is popular for its diagrammatic notations. UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. The model is useless unless its purpose is depicted properly.

So learning notations should be emphasized from the very beginning.

Different notations are available for things and relationships. And the UML diagrams are made using the notations of things and relationships. Extensibility is another important feature which makes UML more powerful and flexible.

Structural Things:

Graphical notations used in structural things are the most widely used in UML.

These are considered as the nouns of UML models. Following are the list of structural things.


45

 Classes

 Interface

 Collaboration

 Use case

 Active classes

 Components

 Nodes

Class Notation:

UML class is represented by the diagram shown below. The diagram is divided into four parts.

 The top section is used to name the class.

 The second one is used to show the attributes of the class.

 The third section is used to describe the operations performed by the class.

 The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.

Object Notation:

The object is represented in the same way as the class. The only difference is the name which is underlined as shown below.


46

As object is the actual implementation of a class which is known as the instance of a class. So it has the same usage as the class.

Interface Notation:

Interface is represented by a circle as shown below. It has a name which is generally written below the circle.

Interface is used to describe functionality without implementation. Interface is the just like a template where you define different functions not the implementation.

When a class implements the interface it also implements the functionality as per the requirement.

Collaboration Notation:

Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the eclipse.


47

Collaboration represents responsibilities. Generally responsibilities are in a group.

Use case Notation:

Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

Use case is used to capture high level functionalities of a system.

Actor Notation:

An actor can be defined as some internal or external entity that interacts with the system.


48

Actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation:

Initial state is defined show the start of a process. This notation is used in almost all diagrams.

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation:

Final state is used to show the end of a process. This notation is also used in almost all diagrams to describe the end.

The usage of Final State Notation is to show the termination point of a process.

Active class Notation:

Active class looks similar to a class with a solid border. Active class is generally used to describe concurrent behaviour of a system.


49

Active class is used to represent concurrency in a system.

Component Notation:

A component in UML is shown as below with a name inside. Additional elements can be added wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation:

A node in UML is represented by a square box as shown below with a name.

A node represents a physical component of the system.

Node is used to represent physical part of a system like server, network etc.


50

Behavioural Things:

Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to represent the dynamic part of software and non software systems. These features include interactions and state machines.

Interactions can be of two types:

 Sequential (Represented by sequence diagram)

 Collaborative (Represented by collaboration diagram)

Interaction Notation:

Interaction is basically message exchange between two UML components. The following diagram represents different notations used in an interaction.


51

Interaction is used to represent communication among the components of a system.

State machine Notation:

State machine describes the different states of a component in its life cycle.

The notations are described in the following diagram.

State machine is used to describe different states of a system component. The state can be active, idle or any other depending upon the situation.

Grouping Things:

Organizing the UML models are one of the most important aspects of the design. In UML there is only one element available for grouping and that is package.


52

Package Notation:

Package notation is shown below and this is used to wrap the components of a system.

Annotational Things:

In any diagram explanation of different elements and their functionalities are very important. So UML has notes notation to support this requirement.

Note Notation:

This notation is shown below and they are used to provide necessary information of a system.

Relationships

A model is not complete unless the relationships between elements are described properly. The Relationship gives a proper meaning to an UML model. Following are the different types of relationships available in UML.


53

 Dependency

 Association

 Generalization

 Extensibility

Dependency Notation:

Dependency is an important aspect in UML elements. It describes the dependent elements and the direction of dependency.

Dependency is represented by a dotted arrow as shown below. The arrow head represents the independent element and the other end the dependent element.

Dependency is used to represent dependency between two elements of a system.

Generalization Notation:

Generalization describes the inheritance relationship of the object oriented world. It is parent and child relationship.

Generalization is represented by an arrow with hollow arrow head as shown below. One end represents the parent element and the other end child element.

Generalization is used to describe parent-child relationship of two elements of a system.


54

Association Notation:

Association describes how the elements in an UML diagram are associated. In simple word it describes how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two associated elements as shown below. The multiplicity is also mentioned at the ends (1, * etc) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Extensibility Notation:

All the languages (programming or modeling) have some mechanism to extend its capabilities like syntax, semantics etc. UML is also having the following mechanisms to provide extensibility features.

 Stereotypes (Represents new elements)

 Tagged values (Represents new attributes)

 Constraints (Represents the boundaries)


55

Extensibility notations are used to enhance the power of the language. It is basically additional elements used to represent some extra behaviour of the system.

These extra behaviours are not covered by the standard available notations.

Use case

Overview:

To model a system the most important aspect is to capture the dynamic behaviour.

To clarify a bit in details, dynamic behaviour means the behaviour of the system when it is running /operating.

So only static behaviour is not sufficient to model a system rather dynamic behaviour is more important than static behaviour. In UML there are five diagrams available to model dynamic nature and use case diagram is one of them. Now as we have to discuss that the use case diagram is dynamic in nature there should be some internal or external factors for making the interaction.

These internal and external agents are known as actors. So use case diagrams are consists of actors, use cases and their relationships. The diagram is used to model the system/subsystem of an application. A single use case diagram captures a particular functionality of a system.

So to model the entire system numbers of use case diagrams are used.


56

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose.

Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the same purpose. So we will look into some specific purpose which will distinguish it from other four diagrams.

Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalities use cases are prepared and actors are identified.

Now when the initial task is complete use case diagrams are modelled to present the outside view.

So in brief, the purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.

 Identify external and internal factors influencing the system.

 Show the interacting among the requirements are actors.

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the requirements of a system are analyzed the functionalities are captured in use cases.

So we can say that uses cases are nothing but the system functionalities written in an organized manner. Now the second things which are relevant to the use cases are the actors. Actors can be defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications. So in a brief when we are planning to draw an use case diagram we should have the following items identified.


57



 Functionalities to be represented as an use case

 Actors

Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.

 The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionalities performed.

 Give a suitable name for actors.

 Show relationships and dependencies clearly in the diagram.

 Do not try to include all types of relationships. Because the main purpose of

 the diagram is to identify requirements.

Use note when ever required to clarify some important points.

The following is a sample use case diagram representing the order management system. So if we look into the diagram then we will find three use cases (Order,

SpecialOrder and NormalOrder) and one actor which is customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have extends relationship. Another important point is to identify the system boundary which is shown in the picture. The actor Customer lies outside the system as it is an external user of the system.


58

Where to Use Case Diagrams?

As we have already discussed there are five diagrams in UML to model dynamic view of a system. Now each and every model has some specific purpose to use. Actually these specific purposes are different angles of a running system.

So to understand the dynamics of a system we need to use different types of diagrams. Use case diagram is one of them and its specific purpose is to gather system requirements and actors.

Use case diagrams specify the events of a system and their flows. But use case diagram never describes how they are implemented. Use case diagram can be imagined as a black box where only the input, output and the function of the black box is known.

These diagrams are used at a very high level of design. Then this high level design is refined again and again to get a complete and practical picture of the system. A well structured use case also describes the pre condition, post condition, exceptions. And these extra elements are used to make test cases when performing the testing.


59

Although the use cases are not a good candidate for forward and reverse engineering but still they are used in a slight different way to make forward and reverse engineering. And the same is true for reverse engineering. Still use case diagram is used differently to make it a candidate for reverse engineering.

In forward engineering use case diagrams are used to make test cases and in reverse engineering use cases are used to prepare the requirement details from the existing application.

So the following are the places where use case diagrams are used:

 Requirement analysis and high level design.

 Model the context of a system.

 Reverse engineering.

 Forward engineering.

UML Class Diagram

Overview:

The class diagram is a static diagram. It represents the static view of an application.

Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application.

The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram.


60

Purpose:

The purpose of the class diagram is to model the static view of an application.

The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction.

The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community.

So the purpose of the class diagram can be summarized as:

 Analysis and design of the static view of an application.

 Describe responsibilities of a system.

 Base for component and deployment diagrams.

 Forward and reverse engineering.

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications. So it is very important to learn the drawing procedure of class diagram.

Class diagrams have lot of properties to consider while drawing but here the diagram will be considered from a top level view.

Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application. So a collection of class diagrams represent the whole system.

The following points should be remembered while drawing a class diagram:

 The name of the class diagram should be meaningful to describe the aspect of the system.

 Each element and their relationships should be identified in advance.

 Responsibility (attributes and methods) of each class should be clearly identified.


61





For each class minimum number of properties should be specified. Because unnecessary properties will make the diagram complicated.

Use notes when ever required to describe some aspect of the diagram.

Because at the end of the drawing it should be understandable to the developer/coder.

 Finally, before making the final version, the diagram should be drawn on

 plain paper and rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So it describes a particular aspect of the entire application.

 First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have

 multiple orders.

We would keep Order class is an abstract class and it has two concrete classes

(inheritance relationship) SpecialOrder and NormalOrder.

 The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:


62

Where to use Class Diagrams?

Class diagram is a static diagram and it is used to model static view of a system. The static view describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams. Class diagrams are not only used to visualize the static view of the system but they are also used to construct the executable code for forward and reverse engineering of any system.

Generally UML diagrams are not directly mapped with any object oriented programming languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object oriented languages like

Java, C++ etc. So from practical experience class diagram is generally used for construction purpose.


63

So in a brief, class diagrams are used for:

 Describing the static view of the system.

 Showing the collaboration among the elements of the static view.

 Describing the functionalities performed by the system.

 Construction of software applications using object oriented languages.

UML Interaction Diagram

Overview:

From the name Interaction it is clear that the diagram is used to describe some type of interactions among the different elements in the model. So this interaction is a part of dynamic behaviour of the system.

This interactive behaviour is represented in UML by two diagrams known as

Sequence diagram and Collaboration diagram. The basic purposes of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the structural organization of the objects that send and receive messages.

Purpose:

The purposes of interaction diagrams are to visualize the interactive behaviour of the system. Now visualizing interaction is a difficult task. So the solution is to use different types of models to capture the different aspects of the interaction.

That is why sequence and collaboration diagrams are used to capture dynamic nature but from a different angle.

So the purposes of interaction diagram can be describes as:

 To capture dynamic behaviour of a system.

 To describe the message flow in the system.


64

 To describe structural organization of the objects.

 To describe interaction among objects.

How to draw Interaction Diagram?

The purpose of interaction diagrams are to capture the dynamic aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic aspect is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running system at a particular moment.

We have two types of interaction diagrams in UML. One is sequence diagram and the other is a collaboration diagram. The sequence diagram captures the time sequence of message flow from one object to another and the collaboration diagram describes the organization of objects in a system taking part in the message flow.

So the following things are to identified clearly before drawing the interaction diagram:

 Objects taking part in the interaction.

 Message flows among the objects.

 The sequence in which the messages are flowing.

 Object organization.

Following are two interaction diagrams modeling order management system. The first diagram is a sequence diagram and the second is a collaboration diagram.

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).

The following diagram has shown the message sequence for SpecialOrder object and the same can be used in case of NormalOrder object. Now it is important to understand the time sequence of message flows. The message flow is nothing but a method call of an object.


65

The first call is sendOrder () which is a method of Order object. The next call is confirm

() which is a method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder object. So here the diagram is mainly describing the method calls from one object to another and this is also the actual scenario when the system is running.

The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as shown below. Here in collaboration diagram the method call sequence is indicated by some numbering technique as shown below. The number indicates how the methods are called one after another. We have taken the same order management system to describe the collaboration diagram.

The method calls are similar to that of a sequence diagram. But the difference is that the sequence diagram does not describe the object organization where as the collaboration diagram shows the object organization.


66

Now to choose between these two diagrams the main emphasis is given on the type of requirement. If the time sequence is important then sequence diagram is used and if organization is required then collaboration diagram is used.

Where to use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe dynamic nature of a system. Now we will look into the practical scenarios where these diagrams are used. To understand the practical application we need to understand the basic nature of sequence and collaboration diagram.

The main purposes of both the diagrams are similar as they are used to capture the dynamic behaviour of a system. But the specific purposes are more important to clarify and understood.

Sequence diagrams are used to capture the order of messages flowing from one object to another. And the collaboration diagrams are used to describe the structural organizations of the objects taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of an entire system so a set of diagrams are used to capture is as a whole.


67

The interaction diagrams are used when we want to understand the message flow and the structural organization. Now message flow means the sequence of control flow from one object to another and structural organization means the visual organization of the elements in a system.

In a brief the following are the usages of interaction diagrams:

 To model flow of control by time sequence.

 To model flow of control by structural organizations.

 For forward engineering.

 For reverse engineering.

UML Activity Diagram

Overview:

Activity diagram is another important diagram in UML to describe dynamic aspects of the system.

Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic behaviour of the system. Other four diagrams are used to show the message flow from one object to another but activity diagram is used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. The only missing thing in activity diagram is the message part.


68

It does not show any message flow from one activity to another. Activity diagram is some time considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.

 Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system. But activity diagram are not exactly a flow chart as they have some additional capabilities. These additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements used in activity diagram. The main element of an activity diagram is the activity itself. An activity is a function performed by the system. After identifying the activities we need to understand how they are associated with constraints and conditions.

So before drawing an activity diagram we should identify the following elements:

 Activities

 Association

 Conditions

 Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the entire flow. This mental layout is then transformed into an activity diagram.

The following is an example of an activity diagram for order management system. In the diagram four activities are identified which are associated with conditions. One


69

important point should be clearly understood that an activity diagram cannot be exactly matched with the code. The activity diagram is made to understand the flow of activities and mainly used by the business users.

The following diagram is drawn with the four main activities:

 Send order by the customer

 Receipt of the order

 Confirm order

 Dispatch order

After receiving the order request condition checks are performed to check if it is normal or special order. After the type of order is identified dispatch activity is performed and that is marked as the termination of the process.

Where to use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams.

The specific usage is to model the control flow from one activity to another. This control flow does not include messages.


70

The activity diagram is suitable for modeling the activity flow of the system.

An application can have multiple systems. Activity diagram also captures these systems and describes flow from one system to another. This specific usage is not available in other diagrams. These systems can be database, external queues or any other system.

This diagram is used to model the activities which are nothing but business requirements. So the diagram has more impact on business understanding rather implementation details.

Following are the main usages of activity diagram:

 Modeling work flow by using activities.

 Modeling business requirements.

 High level understanding of the system's functionalities.

 Investigate business requirements at a later stage.

UML Package Diagram

Package diagrams organize the elements of a system into related groups to minimize dependencies among them.

Packages

Use a tabbed folder to illustrate packages. Write the name of the package on the tab or inside the folder. Similar to classes, you can also list the attributes of a package.


71

Visibility

Visibility markers signify who can access the information contained within a package. Private visibility means that the attribute or the operation is not accessible to anything outside the package. Public visibility allows an attribute or an operation to be viewed by other packages. Protected visibility makes an attribute or operation visible to packages that inherit it only.

Dependency

Dependency defines a relationship in which changes to one package will affect another package. Importing is a type of dependency that grants one package access to the contents of another package.

UML sequence diagram

UML sequence diagrams are used to represent or model the flow of messages, events and actions between the objects or components of a system. Time is represented in the vertical direction showing the sequence of interactions of the header elements, which are displayed horizontally at the top of the diagram.


72

Sequence Diagrams are used primarily to design, document and validate the architecture, interfaces and logic of the system by describing the sequence of actions that need to be performed to complete a task or scenario. UML sequence diagrams are useful design tools because they provide a dynamic view of the system behavior which can be difficult to extract from static diagrams or specifications.

Although UML sequence diagrams are typically used to describe objectoriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence charts and call flows for telecom/wireless system design, and for protocol stack design and analysis.

Sequence Diagram Drawing Elements

This tutorial describes the basic drawing elements used in sequence diagrams and when they are used. Some are not part of the UML specification and may not be supported by other UML tools.

Sequence Diagram Header Elements

The header portion of the sequence diagram represents the components or objects of the system being modeled and are laid out horizontally at the top of the diagram.

See an example sequence diagram here.

Actor Represents an external person or entity that interacts with the system

Object Represents an object in the system or one of its components

Unit Represents a subsystem, component, unit, or other logical entity in the system (may or may not be implemented by objects)

Separator Represents an interface or boundary between subsystems, components or units (e.g., air interface, Internet, network)


73

Group Groups related header elements into subsystems or components

Sequence Diagram Body Elements

Action Represents an action taken by an actor, object or unit

Asynchronous

Message

Block

An asynchronous message between header elements

A block representing a loop or conditional for a particular header element

Call Message A call (procedure) message between header elements

Create Message A "create" message that creates a header element (represented by lifeline going from dashed to solid pattern)

Destroy

Element

Represents the destruction of a header element

Destroy

Message

Represents the destruction of a header element as a result of a call from another element

Diagram Link Represents a portion of a diagram being treated as a functional block. Similar to a procedure or function call that abstracts functionality or details not shown at this level. Can optionally be linked to another diagram for elaboration.

Else Block Represents an "else" block portion of a diagram block

Flow Note

Free Note

Documentation note that is automatically formatted to flow after previous elements

Documentation note that is free-flowing


74

Message

Page Break and can be placed anywhere in the diagram (can also be anchored relative to a flow element)

A simple message between header elements

A page break in the diagram

Return Message A return message between header elements

Scenario Start Start of a scenario (set of alternatives)

Scenario Case Start of an alternative or case in a scenario

Scenario End End of a scenario

State A state change for a header element

Steady State A steady state in the system

Timer Start

Timer Stop

Start of a timer for a particular header element

Stop of a timer for a particular header element

Timer

Expiration

Expiration of a timer for a particular header element

State Diagrams

State diagrams are a familiar technique to describe the behavior of a system.

They describe all of the possible states that a particular object can get into and how the object's state changes as a result of events that reach the object. In most OO techniques, state diagrams are drawn for a single class to show the lifetime behavior of a single object.

There are many forms of state diagrams, each with slightly different semantics. The UML style is based on David Harel's (1987) statechart. Figure shows a UML state diagram for an order in the order processing system I introduced earlier in the book. The diagram indicates the various states of an order.


75

Figure State Diagram

Figure shows a UML state diagram for an order in the order processing system I introduced earlier in the book. The diagram indicates the various states of an order.

We begin at the start point and show an initial transition into the Checking state.

This transition is labeled "/get first item."


76

The syntax for a transition label has three parts, all of which are optional: Event

[Guard] / Action. In this case, we have only the action "get first item." Once we perform that action, we enter the Checking state. This state has an activity associated with it, indicated by a label with the syntax do/activity. In this case, the activity is called "check item."

Note that I used the terms "action" for the transition and "activity" for the state.

Although they are both processes, typically implemented by some method on Order, they are treated differently. Actions are associated with transitions and are considered to be processes that occur quickly and are not interruptible. Activities are associated with states and can take longer. An activity may be interrupted by some event. Note that the definition of "quickly" depends on the kind of system you are producing. Within a hard real-time system, "quickly" may mean within a few machine instructions; for regular information systems, "quickly" might mean less than a few seconds.

Note that the definition of "quickly" depends on the kind of system you are producing. Within a hard real-time system, "quickly" may mean within a few machine instructions; for regular information systems, "quickly" might mean less than a few seconds.

When a transition has no event within its label, it means that the transition occurs as soon as any activity associated with the given state is completed. In this case, that means as soon as we are done with the Checking. Three transitions come out of the

Checking state. All three have only guards on their label. A guard is a logical condition that will return only "true" or "false." A guarded transition occurs only if the guard resolves to "true."

Only one transition can be taken out of a given state, so we intend the guards to be mutually exclusive for any event. in Figure , we address three conditions.

1.

If we have not checked all items, we get the next item and return to the

Checking state to check it.

2.

If we have checked all items and they were all in stock, we transition to the

Dispatching state.


77

3.

If we have checked all items but not all of them were in stock, we transition to the Waiting state.

I'll look at the Waiting state first. There are no activities for this state, so the given order sits in this state, waiting for an event. Both transitions out of the Waiting state are labeled with the Item Received event. This means that the order waits until it detects this event. At that point, it evaluates the guards on the transitions and makes the appropriate transition, either to Dispatching or back to Waiting.

Within the Dispatching state, we have an activity that initiates a delivery. There is also a single, unguarded transition triggered by the Delivered event. This indicates that the transition will always occur when that event occurs. Note, however, that the transition does not occur when the activity completes; instead, once the "initiate delivery" activity is finished, the given order remains in the Dispatching state until the Delivered event occurs.

The final thing to address is a transition named "cancelled." We want to be able to cancel an order at any point before it is delivered. We could do this by drawing separate transitions from each of the Checking, Waiting, and Dispatching states. A useful alternative is to create a superstate of all three states and then draw a single transition from that. The substates simply inherit any transitions on the superstate.


78

Figure (a) State Diagram without Superstates


79

Figure (b). State Diagram with Superstates

Even with only three duplicated transitions, Figure (a) looks rather cluttered. Figure

(b) makes the whole picture much clearer, and if changes are needed later, it is harder to forget the cancelled event.

In the current examples, I have shown an activity within a state, indicated by text in the form do/activity. You can also indicate other things within a state.

If a state responds to an event with an action that does not cause a transition, you can show this by putting text in the form eventName / actionName in the state box.

There are a couple of other types of events in addition to named events from the outside.

 An event can be generated after a period of time. You indicate this with the keyword after. For instance, you might say after (20 minutes).


80

 An event can be generated when a condition becomes true. You show this with the keyword when. For example, you could have when(temparature > 100

degrees).

There are also two special events, entry and exit. Any action that is marked as linked to the entry event is executed whenever the given state is entered via a transition.

The action associated with the exit event is executed whenever the state is left via a transition. If you have a transition that goes back to the same state (this is called a

self-transition) with an action, the exit action would be executed first, then the transition's action, and finally the entry action. If the state has an associated activity as well, that activity is executed after the entry action.

Concurrent State Diagrams

In addition to states of an order that are based on the availability of the items, there are also states that are based on payment authorization. If we look at these states, we might see a state diagram like the one in Figure (c)


81

Figure (c). Payment Authorization

Here we begin by doing an authorization. The "check payment" activity finishes by signaling that the payment is approved. If the payment is OK, the given order waits in the Authorized state until the "deliver" event occurs. Otherwise, the order enters the Rejected state.

The Order object exhibits a combination of the behaviors shown in Figure (a) and

Figure (b). The associated states and the Cancelled state discussed earlier can be combined on a concurrent state diagram (see Figure (c)).


82

Figure (c) Concurrent State Diagram

Note that in Figure (c), I left out details of the internal states.

The concurrent sections of the state diagram are places in which at any point, the given order is in two different states, one from each diagram. When the order leaves the concurrent states, it is in only a single state. We can see that an order starts off in both the Checking and Authorizing states. If the "check payment" activity of the

Authorizing state completes successfully first, the order will be in the Checking and

Authorized states. If the "cancel" event occurs, the order will be in only the Cancelled state.

Concurrent state diagrams are useful when a given object has sets of independent behaviors. Note, however, that you should not get too many concurrent sets of behaviors occurring in a single object. If you have several complicated concurrent state diagrams for an object, you should consider splitting the object into separate objects


83

Decomposing an Activity

An activity can be broken down into subactivities. This works much the same as a superstate and substates do on a state diagram. You can just show the superstate on the parent diagram, or you can show the superstate and its internal behavior inside it, as I have in Figure (d). In this case, I've given the delivery activity both a start and an end. You can also draw transitions directly into, or out of, the subsidiary diagram. The advantages of the explicit start and end states are that the delivery activity can be used in other contexts, and the parent diagram is decoupled from the contents of the subsidiary diagram.

Figure (d). Using a Composite Activity for Delivery


84

UNIT - III

OBJECT AND RESPONSIBILTY IDENTIFICATION

OO model traditional techniques

The Systems Development Lifecycle (SDLC)

Systems development life cycle (SDLC) l Provides overall framework for managing systems development process

Two main approaches to SDLC l Predictive approach – assumes project can be planned out in advance l Adaptive approach – more flexible, assumes project cannot be planned out in advance

All projects use some variation of SDLC

Traditional Predictive Approach to the SDLC

1.

Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project

2.

Analysis – understand business needs and processing requirements

3.

Design – define solution system based on requirements and analysis decisions

4.

Implementation – construct, test, train users, and install new system

5.

Support – keep system running and improve

Waterfall” Approach to the SDLC


85

Two Approaches to System Development

Traditional approach

1.

Also called structured system development

2.

Structured analysis and design technique (SADT)

3.

Includes information engineering (IE)

Object-oriented approach

1.

Also called OOA, OOD, and OOP

2.

Views information system as collection of interacting objects that work together to accomplish tasks


86

Current techniques –Object Oriented Approach

1.

Completely different approach to information systems

2.

Views information system as collection of interacting objects that work together to accomplish tasks a.

Objects – things in computer system that can respond to messages b.

Conceptually, no processes, programs, data entities, or files are defined

– just objects

3.

OO languages: Java, C++, C# .NET, VB .NET

Techniques

1.Object-oriented analysis (OOA) l Defines types of objects users deal with l Shows use cases are required to complete tasks

2.Object-oriented design (OOD) l Defines object types needed to communicate with people and devices in system l Shows how objects interact to complete tasks l Refines each type of object for implementation with specific language of environment

3.Object-oriented programming (OOP) l Writing statements in programming language to define what each type of object does

Object-oriented (OO) methods

OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures. In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs

Services


87

_ Objects provide services to other objects in their environments. For example, a physician object mayprovide services examine, report._ Coad distinguishes three types of services:

• Occurence services, whereby objects are created,destroyed, changed,...;

• Calculate services, where an object performs acalculation for some other object;

• Monitor services, where an object is monitoring someprocess to see if some condition applies;

_ A special notation is used (dashed-line arrow) to indicatethat an object is using services from another object

Identifying attributes

In object-oriented software design (OOD), classes are templates for defining the characteristics and operations of an object. Often, classes and objects are used interchangeably, one synonymous with the other. In actuality, a class is a specification that an object implements.

Identifying classes can be challenging. Poorly chosen classes can complicate the application

� s logical structure, reduce reusability, and hinder maintenance. This article provides a brief overview of object-oriented classes and offers tips and suggestions to identify cohesive classes.

Note: The following class diagrams were modeled using Enterprise Architect . Many other modeling tools exist. Use the one that is best suited for your purpose and project.

Classes

Object-oriented classes support the object-oriented principles of abstraction, encapsulation, polymorphism and reusability. They do so by providing a template, or blueprint, that defines the variables and the methods common to all objects that are based on it. Classes specify knowledge (attributes) - they know things - and behavior (methods) - they do things.

Classes are specifications for objects.


88

Derived from the Use Cases , classes provide an abstraction of the requirements and provide the internal view of the application.

Attributes

Attributes define the characteristics of the class that, collectively, capture all the information about the class. Attributes should be protected by their enclosing class.

Unless changed by the class

�

behavior, attributes maintain their values.

The type of data that an attribute can contain is determined by its data type. There are two basic data types: Primitive and Derived.

1.

Primitive data types are fundamental types. Examples are integer, string, float.

2.

Derived data types are defined in terms of the Primitive data types, that is, they form new data types by extending the primitive data types. A Student class, for example, is a derived data type formed by a collection of primitive data types.

When defined in the context of a problem domain, derived data types are called

Domain Specific Data types. These are the types that define and constrain attributes to be consistent with the semantics of the data. For example, Address studentAddress versus string studentAddress.

Where practical, design models should use domain specific data types in lieu of primitive data types.

When looking for attributes in the design model, look for these types:

1.

Descriptive attributes provide intrinsic information about the class. For example, information about enrollment status, test scores, and education goals would be intrinsic to a Student class but not an Automobile class. Ask,

�

What characteristics distinguish this class from others?

�

2.

Naming attributes are used to uniquely identify an object and typically don

� t change during the lifetime of the object. Consider two Student objects


89

that contain the naming attribute, studentName. The values of

�

Jack

�

and

�

Jill

�

would identify two different Student objects. Ask,

�

What uniquely identifies this object from another object of the same class?

�

3.

Referential attributes contain links to objects. A student

� s test scores might be stored in an Assessment class, for example. The value for the Assessment attribute (in the Student class) would link the Student class to the Assessment class. Ask,

�

How is this object associated with other objects?

�

Responsibilities

A class has behaviors and responsibilities. A responsibility is something that a class knows or does

� it

� s an obligation a class has to know certain information and/or to perform a task. For example, a student knows about her address and SSN. A student does enroll in a class.

Technically, responsibilities are not the same as the class

�

operations (behavior), but, operations fulfill the responsibilities. It may take more than one operation

(sometimes, more than one object) to fulfill the responsibility.

Responsibility is the obligation of a class or object to perform a task or know information.

Identifying classes

Identifying object-oriented classes is both a skill and an art. It

� s a process that one gets better at over time. For example, it

� s not unusual for inexperienced designers to identify too many classes. Modeling too many classes results in poor performance, unnecessary complexity and increased maintenance. On the other hand, too few classes tend to increase couplings, and make classes larger and unwieldy. In general, strive for class cohesiveness where behavior is shared between multiple, related classes rather than one very large class.

Cohesive classes reduce coupling, enable extensibility and increase maintainability.


90

Moreover, classes that seem obvious wind up being poor choices and classes that are initially hidden or that rely on problem domain knowledge wind up as the best choices.

Therefore, begin class modeling by identifying candidate classes - an initial list of classes from which the actual design classes will emerge. Design classes are the classes that are modeled. Candidate classes exist for the sole purpose of deriving the design classes. Initially, there will be a lot of candidate classes

�

that

� s good.

However, through analysis, their number will be reduced as they are dropped, combined and merged.

Candidate classes provide the initial impetus to produce cohesive classes.

Candidate classes can be discovered in a variety of ways. Here are three:

1.

Noun and noun phrases : Identify the noun and noun phrases, verbs (actions) and adjectives (attributes) from the Use Cases, Actor-Goal List, Application

Narrative and Problem Description.

2.

CRC cards : an informal, group approach to object modeling.

3.

GRASP : A formal set of principles that assign responsibilities.

Each of these methods will yield a list candidate classes. The list won

� t be complete nor will every class be appropriate and there will likely be a mix of business and system oriented classes; i.e.; Student and StudentRecord, for example. That

� s fine.

The goal is to identify the major classes - the obvious ones. Other classes will become apparent as the design process continues.

Once the list has been created, analyze the candidate classes for associations with other classes. Look for collaborating classes. How does each relate to each other and to the business process? Sometimes, it

� s helpful to ask,

�

Why keep this class?

�

In other words, assume the class is redundant or unnecessary. Keep it only if it plays a collaborating role. Often you

� ll find the class

�

functionality is accomplished by another class or within the context of another class.


91

TRADITIONAL TECHNIQUES

Noun phrase approach:

Nouns in the textual description are considered to be classes and verbs to be methods of the classes. All plurals are changed to singular, the nouns are listed and the list divided into relevant classes, fuzzy classes and irrelevant class.

Look for the noun phrases through the use cases.

 Three categories:

 Relevant classes.

 Fuzzy classes.

 Irrelevant classes.

 Identifying tentative classes.

 Look for noun phrases and nouns in the use cases.

 Some classes are implicit or taken from general knowledge.

 All classes must make sense in the application domain.

 Carefully choose and define class names.

 Selecting classes from the relevant and fuzzy classes.





Redundant classes.

 Adjective classes.

 Attribute classes.

Irrelevant classes.

Guide lines for selecting classes in all application:

 Carefully choose and define class names.

 All classes must make sense in the application domain, avoid computer implementation classes – defer there to the design stage.





Look for nouns and noun-phrases in the use cases.

Some classes are implicit or taken from general knowledge.

CRC Cards:-

In the late 1980s, one the biggest centers of object technology was the research labs of


92

Tektronix, in Portland, Oregon. These labs had some of the main users of Smalltalk, and many key ideas in object technology were developed there. Two renowned

Smalltalk programmers there were Ward Cunningham and Kent Beck.

Cunningham and Beck were and are concerned about how to teach the deep knowledge of Smalltalk they had gained. From this question of how to teach objects came the simple technique of Class-Responsibility-Collaboration (CRC) cards.

Rather than use diagrams to develop models, as most methodologists did, Ward represented classes on 4 × 6 index cards. And rather than indicate attributes and methods on the cards, he wrote responsibilities.

So what is a responsibility? It is really a high-level description of the purpose of the class. The idea is to try to get away from a description of bits of data and process and instead capture the purpose of the class in a few sentences. The choice of a card is deliberate. You are not allowed to write more than will fit on the card.(See Figure)

The second C refers to collaborators. These represent the other classes that this class needs to work with. This gives you some idea of the links between classes-still at a high level.

One of the chief benefits of CRC cards is that they encourage animated discussion among the developers. When you are working through a use case to see how classes will implement it, the interaction diagrams in this chapter can be slow to draw.

Usually you need to consider alternatives, and with diagrams, the alternatives take too long to draw and rub out. With CRC cards, you model the interaction by picking up the cards and moving them around. This allows you to quickly consider alternatives.

As you do this, you form ideas about responsibilities and write them on the cards.

Thinking about responsibilities is important, because it gets you away from classes as dumb data holders and eases the team members toward understanding the higher-level behavior of each class. A responsibility may correspond to an operation, to an attribute, or (more likely) to an undetermined clump of attributes and operations.

Figure Class-Responsibility-Collaboration (CRC) Card


93

A common mistake I see people make is generating long lists of low-level responsibilities. This is really missing the point. The responsibilities should easily fit on a card. I would question any card with more than three responsibilities. Ask yourself whether the class should be split or whether the responsibilities would be better stated by rolling them up into higher-level statements.

When to Use CRC Cards

Use CRC cards to help explore an interaction between classes, typically to show how a scenario is implemented. Once you've figured out how the interaction works, you can document it with interaction diagrams.

Use responsibilities to help you summarize the key responsibilities of a class. They are useful in highlighting cluttered classes.

Many people stress the importance of role-playing, where each person on the team


94

plays the role of one or more classes. I've never seen Ward or Kent do that, and I find it gets in the way.



CRC cards have emerged as a simple yet marvelously effective way to analyze scenarios.

 First proposed by Beck and Cunningham as a tool for teaching object-oriented programming.



CRC cards have proven to be a useful development tool that facilitates brainstorming and enhances communication among developers.



A CRC card is nothing more than a 3x5 index card,39 upon which the analyst writes - in pencil - the name of a class (at the top of the card), its responsibilities (on one half of the card) and its collaborators (on the other half of the card).



One card is created for each class identified as relevant to the scenario.



As the team walks through the scenario, they may assign new responsibilities to an existing class, group certain responsibilities to form a new class, or (most commonly) divide the responsibilities of one class into more fine-grained ones, and perhaps distribute these responsibilities to a different class.



CRC cards can be spatially arranged to represent patterns of collaboration.



As viewed from the dynamic semantics of the scenario, the cards are arranged to show the flow of messages among prototypical instances of each class; as viewed from the static semantics of the scenario, the cards are arranged to represent generalization/specialization or aggregation hierarchies among the classes.

Informal English Description:-


95



A radical alternative to classical object-oriented analysis was first proposed by

Abbott, who suggests writing an English description of the problem (or a part of a problem) and then underlining the nouns and verbs .



The nouns represent candidate objects, and the verbs represent candidate operations upon them.



This technique lends itself to automation, and such a system has been built at the Tokyo Institute of Technology and at Fujitsu .



Abbott's approach is useful because it is simple and because it forces the developer to work in the vocabulary of the problem space.



However, it is by no means a rigorous approach, and it definitely does not scale well to anything beyond fairly trivial problems.



Human language is a terribly imprecise vehicle of expression, so the quality of the resulting list of objects and operations depends upon the writing skill of its author.



Furthermore, any noun can be verbed, and any verb can be nouned; therefore, it is easy to skew the candidate list to emphasize either objects or operations.

Structured Analysis :-

 A second alternative to classical object-oriented analysis uses the products of structured analysis as a front end to object-oriented design.



This technique is appealing only because a large number of analysts are skilled in structured analysis, and many CASE tools exist that support the automation of these methods.


96



Personally, we discourage the use of structured analysis as a front end to object-oriented design, but for some organizations, it is the only pragmatic alternative.



The next two techniques involve analyzing individual data flow diagrams.



Given a particular data flow diagram (using the terminology of Ward/Mellor

[48]), candidate objects may be derived from the following: o External entities o Data stores o Control stores o Control transformations

Candidate classes derive from two sources: o Data flows o Control flows


97

UNIT - IV

BEHAVIOUR SPECIFICATIONS

Where to Document Behavior

Architects document behavior to show how an element behaves when stimulated in a particular way, or to show how an ensemble of elements (up to and including the whole system) react with each other. In an architectural documentation package, behavior can be shown in a number of places, depending on what exactly is being shown:

• In a view’s supporting documentation:

- Behavior has its own section in the element catalog. Here, the behavior of the element is documented.

- Behavior can be part of an element’s interface documentation. The semantics of a resource on an element’s interface can include the element’s (externally visible) behavior that occurs as a result of invoking the resource. Or, in the “Usage Guide” section of an interface document, behavior can be used to explain the effects of a particular usage, that is, a particular sequence of resources utilized. Finally, the architect may choose to specify behavior as part of the implementation notes for an interface, to constrain the developers to implement the interface in a particular fashion.

- Behavior can be used to fill in the “Design Background” section, which includes the results of the analysis. Behavior is often a basis for analysis, and the behaviors that were used to analyze the system for correctness or other quality attributes can be recorded here.

• In the documentation that applies across views, the rationale for why the architecture satisfies its requirements can include behavioral specifications as part of the architect’s justification

What to Document

As mentioned above, a behavioral description supports exploring the range of possible orders of interactions, opportunities for concurrency, and time-based interaction dependencies among system elements. In this section we provide


98

guidance as to what types of things you will want to document in order to reap these benefits. The exact nature of what to model depends on the type of system that is being designed. For example, if the system is a real-time embedded system, you will need to say a lot about timing properties and the ordering of events; whereas, in a banking system you will want to say more about the sequencing of events (e.g., atomic transactions and roll-back procedures). Initially you want to talk about the elements and how they interact, rather than the details of how input data is transformed into outputs. It may be useful to also say something about the constraints on the transformational behavior within elements, in as much as that behavior affects the global behavior of the system.

At a minimum, you will want to model the stimulation of actions and the transfer of information from one element to another. In addition, you may want to model timerelated and ordering constraints on these interactions. If correct behavior depends on restrictions as to the order in which actions must occur or as to combinations of actions that must have occurred before a certain action can be taken, then these things must be documented. The more information that is available and made explicit about the constraints on interactions, the more precise the analysis of system behavior can be, and the more likely it will be that the implementation exhibits the same qualities as those predicted during design.

Types of Communication

Looking at a structural diagram that depicts two interrelated elements, the first questions documentation users ask are “What does the line interconnecting the elements mean?” and “Is it showing the flow of data or control?” A behavioral diagram provides a place to describe these aspects of the transfer of information and the stimulation of actions from one element to another. Table 1 shows examples of these. Data is some kind of structured information that may be communicated through shared files and objects. One element may stimulate another to signal that some task is completed or that a service is required. A combination of the two is possible, as is the case when one element stimulates another to deliver data or when information is passed in messages or as event parameters.


99

In addition to the above, you may want to describe constraints on the interaction between elements in the form of synchronous or asynchronous communication. An

RPC is an example of synchronous communication. The sender and receiver know about each other and synchronize in order to communicate. Messaging is an example of asynchronous communication. The sender does not concern itself with the state of the receiver when sending a message or posting an event. In fact, the sender and receiver may not be aware of the identity of each other. Consider telephone and email as examples of these types of communication. If you make a phone call to someone, they have to be at their phone in order for it to achieve its full purpose. That is synchronous communication. If you send an email message and go on to other business, perhaps without concern for a response, then it is asynchronous.

Constraints on Ordering

In the case of synchronous communication, you probably want to say more than that there is two-way communication. For instance, you may want to state which element initiated the communication and which element will terminate it; you may want to say whether the target of the original message will need to employ the assistance of other elements before it can respond to the original request. Decisions about the level of detail at which you describe a conversation depend upon which types of information you want to get out of the specification. For instance, if you are interested in performance analysis, it is important to know that an element will reach a point in its calculation where it requires additional input, since the length of the total calculation depends not only on the internal calculation, but also on the delay associated with waiting for required inputs. You will probably want to be more specific about certain aspects of the way an element reacts to its inputs. You may want to note whether an element requires all or just some of its inputs to be present before it begins calculating. You may want to say whether it can provide intermediate outputs or only final outputs. If a specific set of events must take place before an element’s action is enabled, that should be specified, as should the circumstances in which a set of events or element interactions will be triggered or the environment in which an output of an element is useful. These types of constraints on interactions provide information that is useful for analyzing the design for functional correctness as well as for extra, functional properties.


100

Clock-Triggered Stimulation

If activities are specified to take place at specific times or after certain intervals of time, some notion of time will need to be introduced into your documentation.

Using two types of clocks is helpful for this purpose. One clock measures calendar time to whatever precision is required for the type of system under construction.

This clock allows you to specify that certain things are to happen at certain times of the day or month. For instance, you may want to specify some behavior differently for weekends and holidays. The other clock counts tics or some other, perhaps more precisely specified, measure of time. This clock allows you to specify periodic actions, for example, directions to check every five minutes and determine how many people are logged on to the system. While it is clearly possible to compute one clock from the other, it is simpler to use both mechanisms when creating your architectural documentation, since these are two different ways of thinking about time.

How to Document Behavior: Notations and Languages

Any notation that supports documenting system behavior must include constructs for describing sequences of interactions. Since a sequence is an ordering in time, it should be possible to show time-based dependencies. Sequences of interactions are displayed as a set of stimuli and the triggered activities ordered into a sequence by some means (e.g., a line, numbering, ordering, from top to bottom). Examples of stimuli are the passage of time and the arrival of an event. Examples of activities are compute and wait. Notation that shows time as a point (e.g., time-out) and time as an interval (e.g., wait for 10 seconds) are normally also provided. As a description of behavior implicitly refers to structure and uses structure, the structural elements can be part of the notation. Therefore in most behavior documentation, you can find representations

• stimulus and activity

• ordering of interactions

• structural elements with some relationships to which the behavior maps

Two different groups of behavioral documentation are available, and the notations to support the documentation of behavior tend to fall into one of two corresponding camps:


101

• static views. One type of documentation, often state based, shows the complete behavior of a structural element or set of elements. This is referred to as a static view of behavior, because it is possible to infer all possible traces through a system given this type of documentation. Static behavioral documentation supports the description of alternatives and repetitions to provide the opportunity of following different paths through a system depending on runtime values. With this type of documentation, it is possible to infer the behavior of the elements in any possible case (arrival of any possible stimulus). Therefore, this type of documentation should be chosen when a complete behavior description is required, as is the case for performing a simulation or when applying static-analysis techniques.

• traces. Another type of documentation shows traces (e.g., interaction diagrams) through the structural elements. Those traces are only complete with regard to what happens in a system in case a specific stimulus arrives. Trace descriptions are by no means complete behavioral descriptions of a system. On the other hand, the union of all possible traces would generate a complete behavioral description. Trace descriptions are easier to design and to communicate because they have a narrow focus. Consequently, if the goal is to understand the system or to analyze a difficult situation that the system has to deal with, a trace-oriented description for the behavior is the first choice. There are many notations available for both types of behavioral documentation. The differences between these methods lay in the emphasis that is put on certain aspects of the behavior (stimulus, activity, ordering, elements). There is also a difference in how much detail can be Described.

Functional requirements are represented as use cases, which help to clarify the understanding of the requirements and the system boundaries. Use-case maps

(UCMs) describe how the use cases work their way through the elements of a system and are used as the basis for defining the messages between the elements, using one of the message-interaction diagrams such as sequence diagrams, collaboration diagrams, or message- sequence charts (MSCs). Once the message interface between the elements is well understood, a static behavioral model may be used to describe the internal behavior of the elements.

This model might be a state-based formalism (such as a statechart, ROOMchart, or

SDL flowchart) or a formalism based on pre- and post-conditions (such as the Z language).


102

Static Behavioral Modeling

Static behavioral modeling shows the complete behavior of a structural element or set of elements. It is possible to infer all of the possible traces through a system given this type of documentation. The state-machine formalism is a good candidate for representing the behavior of architectural elements, because each state is an abstraction of all the possible histories that could lead to that state. Once in a state, it doesn’t matter how the system got there, only that it is there; it will react to the occurrence of a given event in the same way regardless of the system’s particular history at the time the event occurs. Notations are available that allow you also to describe the internal behavior of elements in terms of finite state machines and element-toelement interactions in terms of interprocess communication of various types. These notations allow you to overlay a structural description of the system’s elements with constraints on the interactions and timed reactions to both internal and environmental stimuli. In this section we describe two state-based notations: statecharts, which are extensions to the basic notion of finite state machines, and

ROOMcharts, which further extend the notion to address the needs of objectoriented descriptions of the behavior of real-time systems. We also describe the

Specification and Description Language (SDL) and the Z language.

Although other notations are available, we have chosen these because they allow us to describe the basic concepts of documenting behavior in forms that capture the essence of what you wish to convey to system stakeholders. They are also used as base representations in the tools that you are most likely to encounter. Each notation has been incorporated into one or more development environments that allow you to design, simulate, and analyze your system early in the development process.

Statecharts

A statechart is a formalism that was developed by David Harel in the 1980s for describing reactive systems. Statecharts are powerful graphical notations that allow you to trace the behavior of your system given specific inputs. Statecharts add a number of useful extensions to traditional state diagrams, such as the nesting of states and orthogonal regions (AND states). These provide the expressive power to model abstraction and concurrency.


103

A limitation of finite-state-machine representations is that there is no notion of depth. Statecharts extend the finite-state-machine formalism to support the description of the transformations within a state in terms of nested states. The outer state is called the superstate and inner states are referred to as substates. When the superstate is entered, all substates are initiated at their respective default start state, and they remain active until the superstate is exited. A state runs when all entry conditions are fulfilled. The behavior of any substate can be expanded if desired.

Substates can be related either by sequence (i.e., one state leads to another depending on the occurrence of events) or by concurrency (i.e., states are in orthogonal regions and are activated upon entry to the superstate).

Statecharts have their limitations. Several simplifying assumptions are incorporated into the statechart model. Among these is the assumption that all transitions take zero time. This allows a set of transitions within a substate to replace a single transition at the superstate level. As an example, the transition from entering a state to exiting it is taken to be zero. However if we expanded the state, we might see that there are several transitions within it. Clearly each transition takes time, but this fact is abstracted away in statecharts. Additionally, statecharts do not provide any builtin support for modeling protocols; state transitions are instantaneous and reliable.

These simplifying assumptions allow you to record and analyze your system before many design decisions are made. However as you refine your knowledge of the system, you will want to create more precise descriptions.

The example statechart shown in Figure 2 illustrates the states that some of the

JavaPhoneTM objects (Call, Connection, and Terminal Connection) can be in when a phone connection is established and disconnected. This statechart contains important states and transitions but is by no means complete. Sequence is represented by a single-headed arrow leading from the source state to the target state and is annotated with a pair consisting of the possibly parameterized event that causes the transformation, separated by a slash from any events generated along with the state transition.

Thus a transformation sets in motion the change in state of one system element and the triggering of transformations in others. Concurrency is represented by grouping sets of states into a superstate, where the states are separated by dotted lines and where there are no arcs between the states.


104

Here, the JavaPhone superstate contains the substates: Call, Connection, and

Terminal Connection.The default start for each substate is depicted by an arrow that has no source state. At the beginning, Call is in the idle state. As soon as the connect() event arrives, a Connection is created,which transitions into the idle state.

From there commands are exchanged with the telecommunication platform and

Terminal Connections are created. Terminal Connections receive events from the telecommunication platform, which lead to state changes. Those changes trigger state changesin the Connection, which in turn trigger state changes in the Call.

ROOM charts

Real-time object-oriented modeling (ROOM) is an approach to developing software that is particularly designed to support the use of object-oriented design techniques to aid in the development of real-time systems that are driven by scheduling demands. Because ROOM is an object-oriented approach, it supports the use of data abstraction, encapsulation, and inheritance. The primary objects in ROOM descriptions are actors that communicate by exchanging messages. The behavior associated with an actor is documented as a hierarchical state machine and is incorporated into a ROOM chart.

A ROOM chart is a graphical notation that is a close cousin to the state chart. The concepts in ROOM charts are very close to commonly used, object-oriented constructs, thus allowing a smooth transition from the high-level design associated with an architectural description down to the detailed description of the system’s implementation. The desire to include this feature is one of the reasons that state charts were not incorporated directly into ROOM. The developers of ROOM wanted to support describing the details of protocols and scheduling. Supplementing state charts in this way made it necessary to exclude other features. The most notable exclusion is direct support for documenting composite AND states. The lack of this feature does not preclude the representation of orthogonality however. Other features of ROOM can be used to achieve the same goal but with more effort required. One additional feature offered in ROOM is support for the modeling of major concepts associated with object-oriented languages such as inheritance and encapsulation. Behavioral inheritance is also included; thus all features of behavior can be inherited among related actor classes.


105

The developers of ROOM were particularly interested in providing a way to support developing a system in pieces at various levels of detail at the same time. The ROOM modeling environment supports execution of the model and thereby supports simulation of the architecture. Executable ROOMcharts run on a virtual machine provided by the ROOM environment. The virtual machine provides a set of predefined services; others can be defined by users. Among the predefined, interdependent services are timing, processing, and communication services. The timing service supports both types of time mentioned in “Clock-Triggered

Stimulation” This capability to create more precise descriptions required more effort from the modeler and made it necessary to trade off some of the expressive power of statecharts.

Specification and Description Language (SDL)

The SDL is an object-oriented, formal language that was defined by the International

Telecommunication Union (ITU). This language is intended for the specification of complex, event-driven, real-time, and interactive applications involving many concurrent activities that communicate using discrete signals. The most common application is in the telephony area. The accessible SDL can be used in an environment that is constructed of tools that support the documentation, analysis, and generation of systems. Its design was driven by the requirements of developing communication systems; thus it will be particularly useful to you if that is the type of system you are developing. The strength of the SDL is in describing what happens within a system. If the focus is on the interaction between systems, a messageoriented representation such as an MSC is more suitable. SDL specifications are often used in combination with MSCs (discussed later in this report) to explore the behavioral properties of a system. The SDL uses a finite-state-machine formalism at its core to model behavior. The notationfocuses on the transition between states rather than the states themselves, as was the case instatecharts and ROOMcharts.

Constructs for describing the hierarchical structure and the interelementbehavior enhance the capability for modeling large-scale systems.

In the SDL, structure is described in terms of a hierarchy of blocks that is eventually refined into sets of processes as shown in Figure 3. The flow of data and stimulation among blocks and processes is described as signals that travel over named channels.

Signals are the means of communication between blocks and processes.

Communication is asynchronous and specified


106

textually as an annotation attached to a communication channel. Signals are visible to other blocks/processes at lower levels in the hierarchy, rather than enclosing blocks or other blocks at the same level. The internal behavior of a process is described in the finite-state-machine formalism sing the flowchart notation. rocesses run concurrently and independently; concurrent processes have no knowledge of each other’s state. Processes can be instantiated at start-up or while the system is running. The SDL provides a rich set of flowchart symbols, a few of which are used in Figure 4 to describe a simple process that checks a user ID for validity.

The SDL supports user-defined data types and provides several predefined types

(integer, real, natural, Boolean, character, charstring, PId, duration, and time) that have expected meanings. Variables, user-defined data types, and constant data values can be declared. The hierarchy of blocks provides a structural view of the system, while the flow among the blocks and processes combined with process flowcharts describes system behavior. Once these aspects have been documented, it is possible to simulate the system and observe control and data flow through the system as signals pass from block to block and into processes where they move through the flowchart representation of process behavior. This type of simulation allows you to visibly check how your system will react to various stimuli.

Z Language

Z, pronounced “zed,” is a mathematical language based on predicate logic and set theory. The goal for the Z language was that it be a rigorously defined language that would support the formal description of a system’s abstract properties. The Z language focuses on data and its transformations. Systems are specified as sets of

schemas. Schemas are combined using the schema calculus to create a complete behavior. The schema calculus allows type checking. Tools are available for performing type checking as well as other types of behavioral analysis Schemas allow the designer and other users of the specification to focus concern on one small aspect of the system at a time. Simplicity is achieved by breaking a problem into small pieces that can be reasoned about in isolation. A schema is a description of some unit of functionality in terms of a set of variables and the pre- and postconditions of the system state associated with those variables. This allows a great deal of design freedom in that behavior is specified independently of how tasks are performed. The Z language supports a compositional approach


107

to development and thereby provides the benefit of increased tractability when designing large systems. The Z language is particularly useful when you desire to prove properties based on the specification, as is the case when building safetycritical systems. In addition, an array of commercial tools is available to support developing systems based on the Z language. These are some of the reasons that many practitioners who are experienced in the use of the language consider it to be an invaluable tool. However, because it includes a large set of symbols and its expressions are written in terms of predicate logic, it is difficult for some designers to warm up to it.

The ScheduleClass schema shown in Figure 5 defines what it means to add a class to a schedule and provides only the flavor of a Z schema. There are many other constructs available for specifying more complex types of relationships. A description of the schema calculus is beyond the scope of this presentation as are the details of Z type checking and other aspects of the specification language. As mentioned earlier, there are many references available if you are interested in using

Z.

6.2 Trace-Oriented Representations

Trace-oriented representations consist of sequences of activities or interactions that describe the system’s response to a specific stimulus. They document the trace of activities through a system described in terms of its structural elements and their interactions. Although it is conceivable to describe all possible traces through a set of elements to generate the equivalent of a static behavior description, it is not the intention of trace-oriented views to do so. This would reduce the benefit of being readily comprehensible due to the resultant loss of focus. Different techniques emphasize different aspects of behavior:

• Message-oriented techniques focus on describing the message exchange between instances. They show sequences of messages and possibly time dependencies. The basic assumption here is that you will be able to understand and/or build an element if you understand which messages arrive at this element and what the reactions in terms of outgoing messages have to be. Internal features of the element(s) are hidden.


108

• Component-oriented techniques focus on describing which behavioral features an element has to have in order to accommodate the system in performing its functions.

This normally focuses on describing how the interfaces of the elements interact with each other in order to fulfill the system’s functional requirements. Sequences of interactions can be shown, and internal features of the element(s) are hidden.

• Activity-oriented techniques focus on describing which activities have to be performed in order to achieve the purpose of the system. The assumption here is that in order to understand what a system (or element) does (or will do), you need to understand the sequence of activities that it entails. Activity-oriented representations may not even show the elements performing those activities. However, it is assumed that there is some means outside of this specific representation technique that allows the assignment of the described activities to elements.

• Flow-oriented techniques focus on describing the sequencing of responsibilities of elements for a specific scenario or trace. This is useful in understanding concurrency and synchronization. Now, let’s look closer at some of the popular, trace-oriented, representation techniques. We will discuss message-oriented techniques (such as sequence diagrams and MSCs) as well as component-oriented techniques (such as collaboration diagrams and a special version of sequence diagrams, the procedural sequence diagram). In addition we show an example of an activity-oriented representation, which is a use-case diagram, and a flow-oriented representation, which is a UCM.


109

UNIT - V

UML AND PROGRAMMING

UML and Programming

So far, I have discussed a lot of notation. One large question looms: How does a programmer actually use the UML as part of the daily grind of programming? I'll answer this by talking about how I use the UML when I'm programming, even on a small scale. I won't go into a lot of detail, but I hope this will give you a sense of what you can do with the UML.

Let's imagine a computer system designed to pull together information about patients for a hospital. Various health care professionals make observations about patients. This simple system will allow someone to get information about those observations and to add additional observations. As this is a short book, I will wave my arms about the database links and the UI and consider only the basic domain classes.

This is such a simple example that it has but a single use case, named "review and add patient observations." We can elaborate on that with a few scenarios.

 Ask for the latest heart rate of a patient.

 Ask for the blood type of a patient.

 Update a patient's level of consciousness.

 Update a patient's heart rate. The system marks the rate as slow, normal, or fast, according to the system's built-in ranges.

My first step in the process is to come up with a conceptual model that describes the concepts in this domain. At this stage, I'm not thinking about how the software is going to work, only about how to organize concepts in the minds of the doctors and nurses. I'll start with a model based on several analysis patterns from Fowler (1997):

Observation, Quantity, Range, and Phenomenon with Range.


110

Patient Observation: Domain Model

Domain model

A domain model, or Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model of a domain of interest

(often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain. Overview

The domain model is created in order to represent the vocabulary and key concepts of the problem domain. The domain model also identifies the relationships among all the entities within the scope of the problem domain, and commonly identifies their attributes. A domain model that encapsulates methods within the entities is more properly associated with object oriented models. The domain model provides a structural view of the domain that can be complemented by other dynamic views, such as Use Case models.

An important benefit of a domain model is that it describes and constrains the scope of the problem domain. The domain model can be effectively used to verify and validate the understanding of the problem domain among various stakeholders.

It is especially helpful as a communication tool and a focusing point both amongst the different members of the business team as well as between the technical and business teams.

Usage

A well-thought domain model serves as a clear depiction of the conceptual fabric of the problem domain and therefore is invaluable to ensure all stakeholders are aligned in the scope and meaning of the concepts indigenous to the problem domain. A high fidelity domain model can also serve as an essential input to solution implementation within a software development cycle since the model elements comprising the problem domain can serve as key inputs to code construction, whether that construction is achieved manually or through automated code generation approaches. It is important, however, not to compromise the richness and clarity of the business meaning depicted in the domain model by expressing it directly in a form influenced by design or implementation concerns.


111

The domain model is one of the central artifacts in the project development approach called Feature Driven Development (FDD). In UML, a class diagram is used to represent the domain model. In Domain-driven design, the domain model

(Entities and Value objects) is a part of the Domain layer which often also includes other concepts such as Services.

A UML domain model will relate objects in the system domain to each other. It will define concepts and terms. Objects in the domain model can be:

 Physical objects

 Abstract concepts

List Objects (Concepts)

To help the development of a domain model, it is important to identify nouns and noun phrases. Concepts that may not ultimately become objects may be listed for completeness and for discussion. The following types of concepts should be listed:

 Actor roles

 Events

 Transactions o Transaction line items

 Objects (physical) o Containers

 Items (in container) o Other systems o Organizations

 Specification concepts should be used when redundant information is reduced through their use or deleting instances of what the specification describes can result in information loss.

Nouns can be taken from the requirements definitions and use case drawings.

This means at this point all your use case drawings should be done. Actors should not be emphasized in the domain model.


112

If information from an object is derived from another object, that is reason to exclude it. However, if the object is required or is important to the use case, it should be included.

Domain Model Syntax

After the list of concepts is complete a domain model should be made.

Consider which simple items should be attributes of objects. The domain model is a

static model. Time flow, with sequence of events or information flow is not shown in the domain model. Avoid showing procedural relationships. This model does not include software. The objects in the domain model are candidates for programming objects.

There can be multiple relationships between objects in the domain model. For instance an object may handle a single transaction, then make a record of all transactions it handles. In the domain model the following are shown:


113





Concepts (Objects)

Attributes of Objects - Attributes must be simple attributes such as numbers.



They cannot be objects, dimensioned numbers, or keys to part of a database.

 Association between objects

 Multiplicity

 Optional direction of relationship arrow

Optional role of object

Associations

Associations describe important relationships between concepts and may be bidirectional. Use an association to relate classes, not attributes. Some associations may be:

 A is a part of B

 line item of

 Contained inside

 Is a member of

 Is a policy of

 Is next to

 Uses

 Communicates with

 A relates to B due to a transaction

When creating associations, ask yourself, "Does one need to know about the other?".

If the answer is yes, there should probably be an association. There may be more than one association between two objects.

Multiplicity

Describes how many instances of one concept can be associated with one instance of the related concept.

 * = Zero or more

 0..3 = Zero to three

 2,4,6 = Two, four, or six


114

 10 = Exactly 10

 1..* = One or more

 0..* = Zero or more

Some Guidelines

 Put items up in this order:

1.

Concepts

2.

Label associations





3.

Types on attributes

If concepts have both data (attributes) and behavior (methods) they more likely fit in the domain model.

Analyze items that may have additional types.

System design

System design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.

[1][2] If the broader topic of product development "blends the perspective of marketing, design, and manufacturing into a single approach to product development," [3] then design is the act of taking the marketing information and creating the design of the product to be manufactured. Systems design is therefore the process of defining and developing systems to satisfy specified requirements of the user. Until the 1990s systems design had a crucial and respected role in the data processing industry. In the 1990s standardization of hardware and software resulted in the ability to build modular systems. The increasing importance of software running on generic platforms has enhanced the discipline of software engineering.

Object-oriented analysis and design methods are becoming the most widely used methods for computer systems design.

[citation needed] The UML has become the standard language in object-oriented analysis and design.

[citation needed] It is widely used for modeling software systems and is increasingly used for high designing non-software systems and organizations.

[citation needed]


115



Logical design

The logical design of a system pertains to an abstract representation of the data flows, inputs and outputs of the system. This is often conducted via modelling, using an over-abstract (and sometimes graphical) model of the actual system. In the context of systems design are included.

Physical design

The physical design relates to the actual input and output processes of the system.

This is laid down in terms of how data is input into a system, how it is verified/authenticated, how it is processed, and how it is displayed as output.

Physical design, in this context, does not refer to the tangible physical design of an information system. To use an analogy, a personal computer's physical design involves input via a keyboard, processing within the CPU, and output via a monitor, printer, etc. It would not concern the actual layout of the tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard drive, modems, video/graphics cards, USB slots, etc. it involve detail design of user and a product database structure processing and control processor .The H/S personal specification a develop for the proposed system .

Alternative design methodologies

[edit] Rapid application development (RAD)

Rapid application development (RAD) is a methodology in which a systems designer produces prototypes for an end-user. The end-user reviews the prototype, and offers feedback on its suitability. This process is repeated until the end-user is satisfied with the final system.

Joint application design (JAD)

Joint application design (JAD) is a methodology which evolved from RAD, in which a systems designer consults with a group consisting of the following parties:

 Executive sponsor


116

 Systems Designer

 Managers of the system

JAD involves a number of stages, in which the group collectively develops an agreed pattern for the design and implementation of the system.

Systems design: Topics

 Requirements analysis - analyzes the needs of the end users or customers

 Benchmarking — is an effort to evaluate how current systems perform

 Systems architecture - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources. In many cases, multiple architectures are evaluated before one is selected.

 Design — designers will produce one or more 'models' of what they see a system eventually looking like, with ideas from the analysis section either used or discarded. A document will be produced with a description of the system, but nothing is specific — they might say 'touchscreen' or 'GUI

 operating system', but not mention any specific brands;

Computer programming and debugging in the software world, or detailed design in the consumer, enterprise or commercial world - specifies the final system components.

 System testing - evaluates the system's actual functionality in relation to expected or intended functionality, including all integration aspects.

DETAILED DESIGN

Deliver high performing detailed design specifications

Detailed Design is the process of developing a fully defined product design from a clear set of requirements while creating deliverables and documentation appropriate for product manufacturing. Global competition, distributed product development, decreasing product development lifecycles, and increased product complexity put pressure on companies to improve their detailed design process to meet the increasing customer demands for innovative, high-quality products.

Today's detail design process presents enormous challenges. Most companies are


117

operating in a distributed environment, requiring the coordination of design partners and multi-disciplined design teams across time zones and language barriers. Engineers must balance risk and trade-offs while rapidly delivering high performance detailed design specifications that work reliably and offer value.

Changes to requirements are frequent and incorporating those changes into the design process in a managed and controlled way is difficult. Balancing requirements with cost and quality pressures further complicates the process. Design reuse and process automation would be a big help in streamlining what has become an increasingly complex process.

PTC's Product Development System (PDS) delivers all the essential tools for authoring and managing a complete digital product definition. High fidelity 3D product models are developed in a highly productive, Web-connected environment using industry-leading CAD/CAM/CAE capabilities that scale to meet the growing needs of your company. These high-fidelity models capture critical design, analysis and manufacturing information in a single master model, compressing the entire product development cycle.

The complete product information is managed in a single, structured, crossdiscipline product data repository that gives a globally dispersed product development team timely, role-based access to the latest product information.

External partners can be integrated securely and seamlessly into development activities. In addition, PTC’s PDS streamlines and automates many design activities, including design review and electro-mechanical collaboration.

*******


118

OOAD - Vel Tech University

U6CSA24 OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT I OBJECT ORIENTED METHODOLGY

UNIT II UML NOTATIONS

UNIT III OBJECT AND RESPONSIBILTY IDENTIFICATION

UNIT IV BEHAVIOUR SPECIFICATIONS

UNIT V UML AND PROGRAMMING

UNIT I

OBJECT ORIENTED METHODOLGY

Goals of UML

Why Use UML?

UNIT II

UML NOTATIONS

Qualified Associations

Figure Qualified Association

Association Class

Figure. Association Class

Figure . Promoting an Association Class to a Full Class

Figure. Association Class Subtleties

Figure. History Stereotype for Associations

Packages

Visibility

Dependency

Sequence Diagram Header Elements

Sequence Diagram Body Elements

Figure State Diagram

Figure (a) State Diagram without Superstates

Concurrent State Diagrams

Figure (c). Payment Authorization

Figure (c) Concurrent State Diagram

Decomposing an Activity

Figure (d). Using a Composite Activity for Delivery

UNIT - III

OBJECT AND RESPONSIBILTY IDENTIFICATION

Attributes

Responsibilities

Figure Class-Responsibility-Collaboration (CRC) Card

UNIT - IV

BEHAVIOUR SPECIFICATIONS

UNIT - V

UML AND PROGRAMMING

Patient Observation: Domain Model

List Objects (Concepts)

Domain Model Syntax

Associations

Multiplicity

Some Guidelines

System design

[edit] Rapid application development (RAD)

Joint application design (JAD)

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib