×
Expecting to get a good job without studying hard is like expecting to win a marathon without running it.
--Your friends at LectureNotes
Close

Note for Object Oriented Analysis And Design With UML - OOAD by madhavi v

  • Object Oriented Analysis And Design With UML - OOAD
  • Note
  • JNTUK KAKINADA - JNTUK
  • Computer Science Engineering
  • B.Tech
  • 1 Topics
  • 183 Views
  • Uploaded 1 year ago
Madhavi V
Madhavi V
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-2

A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language such as the UML is thus a standard language for software blueprints.” Usages of UML: UML is used in the course to i. document designs design patterns / frameworks ii. represent different views/aspects of design – visualize and construct designs static / dynamic / deployment / modular aspects iii. provide a next-to-precise,common, language –specify visually for the benefit of analysis, discussion, comprehension... abstraction takes precedence over precision! 20/80 rule aim is overview and comprehension; not execution Object Oriented Modeling: Traditionally two approaches to modeling a software system Algorithmically – becomes hard to focus on as the requirements change Object-oriented – models more closely real world entities

Text from page-3

Conceptual Model of the UML: Conceptual Model of UML Building Blocks Rules Things Relationships Diagrams Common Mechanisms 1) Specifications 2) Adornments 3) Common Divisions 4) Extensibility Mechanisms 1. Class Diagram. 1) Association 2. Object Diagram. 2) Dependency 3. Use Case Diagram. 3) Generalization 4. Sequence Diagram. *Stereotypes 4) Realization 5. Collaboration Diagram. *Tagged Values 6. State Chart Diagram. 1) Names *Constraints 7. Activity Diagram. 2) Scope 9. Deployment Diagram. 3) Visibility 4) Integrity 5) Execution Structural Things Behavioral Things Grouping Things Annotational Things *Classes *Interfaces *Collaborations *Use Case *Component *Node *Interaction *State machines *States *Packages *notes

Text from page-4

To understand the UML, you need to form a conceptual model of the language, and this requires learning three major elements: the UML's basic building blocks, the rules that dictate how those building blocks may be put together, and some common mechanisms that apply throughout the UML. Once you have grasped these ideas, you will be able to read UML models and create some basic ones. As you gain more experience in applying the UML, you can build on this conceptual model, using more advanced features of the language. Building Blocks of the UML The vocabulary of the UML encompasses three kinds of building blocks: 1. Things 2. Relationships 3. Diagrams Things are the abstractions that are first-class citizens in a model; relationships tie these things together; diagrams group interesting collections of things. Things in the UML There are four kinds of things in the UML: 1. 2. 3. 4. Structural things Behavioral things Grouping things Annotational things These things are the basic object-oriented building blocks of the UML. You use them to write well-formed models. Structural Things Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. Collectively, the structural things are called classifiers. A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations, as in Figure 2-1. Figure 2-1. Classes

Text from page-5

An interface is a collection of operations that specify a service of a class or component. An interface therefore describes the externally visible behavior of that element. An interface might represent the complete behavior of a class or component or only a part of that behavior. An interface defines a set of operation specifications (that is, their signatures) but never a set of operation implementations. The declaration of an interface looks like a class with the keyword «interface» above the name; attributes are not relevant, except sometimes to show constants. An interface rarely stands alone, however. An interface provided by a class to the outside world is shown as a small circle attached to the class box by a line. An interface required by a class from some other class is shown as a small semicircle attached to the class box by a line, as in Figure 22. Figure 2-2. Interfaces A collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Collaborations have structural, as well as behavioral, dimensions. A given class or object might participate in several collaborations. These collaborations therefore represent the implementation of patterns that make up a system. Graphically, a collaboration is rendered as an ellipse with dashed lines, sometimes including only its name, as in Figure 2-3.

Lecture Notes