Advanced Structural Modeling

OBJECT ORIENTED ANALYSIS AND DESIGN


COURSE HANDOUT

PROGRAM                       : B.Tech., V-Sem., IT, R14 Regulations

ACADEMIC YEAR            : 2018-19

COURSE NAME & CODE  : Object Oriented Analysis and Design

L-T-P STRUCTURE          : 3-1-0                 

COURSE CREDITS          : 3

COURSE INSTRUCTOR   : Dr.B.Rama Devi

PRE-REQUISITE:  software modelling techniques and paradigms.

COURSE OBJECTIVE:

The course Object-Oriented Analysis and Design (OOAD) will expose students to the basics of object-oriented analysis and design using UML (Unified Modeling Language). Learn how to use the UML modeling language and use the notation of UML diagrams such as Activity Diagrams, Use Case, Class, Sequence, etc. Understand how the various models relate to each other and know when to use each model in the system development life cycle. To provide the importance of the software design process.

COURSE OUTCOMES (CO): At the end of the course, the student will be able to

CO1: Select the basic elements of modelling such as things relationships and diagrams    depending   on the   views of UML architecture and SDLC (65)

CO2: Apply basic and advanced structural modelling concepts for designing real time applications (60)  

CO3: Design class and object diagrams that represent static aspects of a software system. (60)

CO4:  Analyze dynamic aspects of a software system using use case, interaction and activity diagrams. (60)

CO5:  Apply techniques of state chart diagrams and implementation diagrams to model the behavioral aspects and run time environment of software system.  (60)

COURSE ARTICULATION MATRIX (Correlation between COs &POs,PSOs):

COs	PO 1	PO 2	PO 3	PO 4	PO 5	PO 6	PO 7	PO 8	PO 9	PO 10	PO 11	PO 12	PSO 1	PSO 2	PSO 3
CO1		1								2	2				3
CO2	3	2	2		3					2	2				3
CO3			2		3					2	2				3
CO4			2	2	3					2	2				3
CO5	2	2	3							2	2				3

Note: Enter Correlation Levels 1 or 2 or 3. If there is no correlation, put ‘-’

         1- Slight(Low), 2 - Moderate(Medium), 3 - Substantial (High).

BOS APPROVED TEXT BOOKS: 

1	Grady booch, James Rumbaugh, Ivar Jacobson “the unified modelling language user guide 2/e, Pearson Education.

BOS APPROVED REFERENCE BOOKS: 

1. Meilir Page-Jones, “Fundamentals of Object Oriented Design in UML”, Pearson Education 2. Pascal Roques, “Modeling Software Systems Using UML2”, WILEY Dream tech India  Pvt Ltd. 3. Atul Kahate,” Object Oriented Analysis & Design”, Tata McGraw-Hil Companies. 4. Craig Larman, “Appling UML and Patterns: An introduction to Object –      Oriented Analysis and Design and Unified Process”, Pearson Education.

Introduction to OOAD:

•  Object-orientation is  referred to as a programming paradigm. It’s not a language itself but a set of concepts that is supported by many languages. Everything we do in  languages is object-oriented, it means, we are oriented or focused around objects.
• Each object contains its own data and its own logic, and they communicate between themselves.These objects aren’t random. They represent the way you talk and think about the problem you are trying to solve in your real life.They represent things like employees, images, bank accounts, spaceships, asteroids, video segment, audio files, or whatever exists in the program.
• In the object-oriented analysis, we …

• Elicit requirements: Define what does the software need to do, and what’s the problem the software trying to solve.
• Specify requirements: Describe the requirements, usually, using use cases (and scenarios) or user stories.
• Conceptual model: Identify the important objects, refine them, and define their relationships and behavior and draw them in a simple diagram.
• Object-Oriented Analysis And Design (OOAD):
• It’s a structured method for analyzing, designing a system by applying the object-orientated concepts, and develop a set of graphical system models during the development life cycle of the software.

• OOAD In The SDLC

  The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment.

  

  The earliest stages of this process are analysis (requirements) and design.
  The distinction between analysis and design is often described as “what Vs how”.
  In analysis developers work with users and domain experts to define what the system is supposed to do. Implementation details are supposed to be mostly or totally ignored at this phase.
  The design phase refines the analysis model and applies the needed technology and other implementation constrains.
• The goal of the analysis phase is to create a model of the system regardless of constraints such as appropriate technology. This is typically done via use cases and abstract definition of the most important objects using conceptual model.
• It focuses on describing the objects, their attributes, behaviour, and interactions. The design model should have all the details required so that programmers can implement the design in code.

• Object-Oriented Design:

  The analysis phase identifies the objects, their relationship, and behavior using the conceptual model (an abstract definition for the objects).
  While in design phase, we describe these objects (by creating class diagram from conceptual diagram — usually mapping conceptual model to class diagram), their attributes, behavior, and interactions.
  The input for object-oriented design is provided by the output of object-oriented analysis. But, analysis and design may occur in parallel, and the results of one activity can be used by the other.
  In the object-oriented design, we …
  • Describe the interaction between the objects using sequence diagram.
  • Apply software design principles and design patterns.
  A class diagram gives a visual representation of the classes you need. And here is where you get to be really specific about object-oriented principles like inheritance and polymorphism.
  Describing the interactions between those objects lets you better understand the responsibilities of the different objects, the behaviour they need to have.
• Object-oriented modelling language  was designed for use in object-oriented software applications. The applications could be based on the object-oriented technologies recommended by the Object Management Group (OMG).
•  UML is a standard language for specifying, visualising, constructing, and documenting the artifacts of software systems.
• UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997.
• UML stands for Unified Modeling Language.
• UML is different from the other common programming languages such as C++, Java, COBOL, etc.
• UML is a pictorial language used to make software blueprints.
• UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system.
• Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.
• UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard.
• In conclusion, the goal of UML can be defined as a simple modelling mechanism to model all possible practical systems in today’s complex environment.

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a conceptual model? and why a conceptual model is required?
A conceptual model can be defined as a model which is made of concepts and their relationships.
A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other.

As UML describes the real-time systems, it is very important to make a conceptual model and then proceed gradually. The 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

Object-Oriented Concepts:

UML can be described as the successor of object-oriented (OO) analysis and design.

An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system. The hierarchy is represented as inheritance and the classes can also be associated in different ways as per the requirement.

Objects are the real-world entities that exist around us and the basic concepts such as abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.

UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design. UML diagrams are representation of object-oriented concepts only. Thus, before learning UML, it becomes important to understand OO concept in detail.

Following are some fundamental concepts of the object-oriented world −

• Objects − Objects represent an entity and the basic building block.
• Class − Class is the blue print of an object.
• Abstraction − Abstraction represents the behavior of an real world entity.
• Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them from the outside world.
• Inheritance − Inheritance is the mechanism of making new classes from existing ones.
• Polymorphism − It defines the mechanism to exists in different forms.
  
  

  1.     Introduction to  Unified Modeling Language (UML)

  
  

                                  The UML is a visual modeling language that enables system builders to create blue prints that capture their visions in a standard, easy-to-understand way, and provides a mechanism to effectively share and communicate these visions with others.

  
  

  A Conceptual Model of the UML:

  
  

                                To understand the UML, you need to form a conceptual model of the language, and this requires learning three major elements: the UML basic building blocks, the rules that dictate how those building blocks may be put together, and some common mechanisms that apply throughout the UML.

  
  

  Building Blocks of the UML:  

             The vocabulary of the UML encompasses three kinds of building blocks:

             

  1.       Things

  2.       Relationships

  3.       Diagrams

  Things: 

                    Things are the abstractions that are first-class citizens in models. There are four kinds of things in the UML:

  
  

  1.       Structural things

  2.       Behavioral things

  3.       Grouping things

  4.       Annotational things

  
  

  1. 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. In all, there are seven kinds of structural things.

  
  

  Class:  A class is a description of 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.

  
  

  Window

  Origin Size

  Open() Close() Move() Display()

  
  

  Interface:   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 set of operation specifications but never a set of operation implementations. Graphically, an interface is rendered as a circle together with its name.

  Collaboration:  Collaboration defines an interface 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. Therefore, collaborations have structural, as well as behavioral, dimensions. Graphically, collaboration is rendered as an ellipse with dashed lines, usually including only its name.

  Use case: A use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model. A use case is realized by collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including its name.

  Active Class:  An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations.

  Component:   A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and tabs usually including only its name.

  Node:   A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. A set of components may reside on a node and may also migrate from node to node. Graphically, a node is rendered as a cube, usually including only its name.

  2. Behavioral Things:

                                           Behavioral things are the dynamic parts of uml models. These are the verbs of a model, representing behavior over time and space. In all, there are two primary kinds of behavioral things.

  
  

  Interaction:   An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. The behavior of a society of objects or of an individual operation may be specified with an interaction. An interaction involves a number of other elements, including messages, action sequences, and links. Graphically, a message is rendered as a directed line, almost always including the name of its operation.

  State Machine:  A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. The behavior of an individual class or a collaboration of class may be specified with a state machine. A state machine involves a number of other elements, including states, transitions, events, and activities. Graphically, a state is rendered as a rounded rectangle, usually including its name and its substances.

  3. Grouping Things:

                                          Grouping things are the organizational parts of uml models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages.

  
  

  Package: A package is a general-purpose mechanism for organizing elements into

  groups. Structural things, behavioral things, and even other grouping things may be placed in package. Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents.

                                          

                                                              

                                                                 Business rules

  
  

  
  

  
  

  
  

  4. Annotational Things:

                                            Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model. There is one primary kind of annotational thing, called a note. A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment.

  Relationships in the UML:

                                                 There are four kinds of relationships in the UML:

  1.     Dependency

  2.     Association

  3.     Generalization

  4.     Realization

  
  

  Dependency:  A dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label.

  
  

   Association:  A association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names.

  
  

  
  

  Generalization:  A generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). In this way, the child shares the structure and the behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with hollow arrowhead pointing to the parent.

   

  Realization:    A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship.

  Diagrams in the UML

                                A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). In theory, a diagram may contain any combination of things and relationships. In practice, however, a small number of common combinations arise, which are consistent with the five most useful views that comprise the architecture of software – intensive system. For this reason, the UML includes nine such diagrams:

  
  

  1. Class Diagram:   A class diagram shows a set of classes, interfaces, and collaborations and their relationships. These diagrams are the most common diagrams found in modeling object-oriented systems. Class diagrams address the static design view of a system.

  
  

  2. Object Diagram:  An object diagram shows a set of objects and their relationship. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases.

  
  

  3. Use Case Diagram:  A use case diagram shows a set of use cases and actors and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system.

  
  

  4. Sequence Diagram:  A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. It’s consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Sequence diagrams address the dynamic view of a system.

  
  

  5. Collaboration Diagram:  A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. It’s consisting of set of objects and their relationships, including the messages that may be dispatched among them. Collaboration diagrams address the dynamic view of a system. Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other.

  
  

  6. Statechart Diagram:  A state chart diagram shows a state machine, consisting of states, transitions, events, and activities. State chat diagrams address the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object.

  
  

  7. Activity Diagram:  An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function the function of a system and emphasize the flow of control among objects.

  
  

  8. Component Diagram:  A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system. They are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations.

  
  

  9. Deployment Diagram:  A deployment diagram show the configuration of run-time processing nodes and the components that live to them. Deployment diagrams address the static deployment view of architecture. They are related to component diagrams in that a node typically encloses one or more components. 
  
  

  2.Rules of the UML

  
  

  
  

          UML has a number of rules that specify what a well-formed model.

         

        The UML has semantic rules for

  
  

  •     Names – things, relationships and diagrams

  •     Scope – specific meaning to a name

  •     Visibility – how these names can be seen and used by o   others

  •     Integrity – things properly and consistently relate to one another

  •     Exception – It means to run or simulate a dynamic model.

  
  

  It is common for the development team to not only build models that are well-formed but also build models that are

  
  

  •     Elided – Certain elements are hidden to simplify the view

  •     Incomplete – Certain elements may missing

  •     Inconsistent – The Integrity of the model is not guarantee

  
  

  Common Mechanisms in the UML

  
  

          There are four common mechanisms that apply consistently throughout the language.

  
  

            1.          Specifications

            2.          Adornments

            3.          Common divisions

            4.          Extensibility mechanisms

  
  

  Specifications:

  
  

          In UML, every part of its graphical notation, there is a specification that provides a textual statement of the syntax and semantics of the building block.

  For example, behind a class icon is a specification that provides the full set of attributes, operations and behaviors.  You use the UML’s graphical notation to visualize a system; you use the UML’s specification to state the system’s details.

  
  

  Adornments: Most elements in the uml have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element.

   A class’s specification may include other details, such as whether it is abstract or the visibility of its attributes and operations. Many of these details can be rendered as graphical or textual adornments to the class’s basic rectangular notation. For example figure shows a class, adorned to indicate that it is an abstract class with two public, one protected, and one private operation.

  
  

  
  

  Transaction

  + execute() + rollback() # priority() - timestamp()

  
  

  Adornments

  
  

  Every element in the UML’s notation starts with a basic symbol, to which can be added a variety in at adornments specific to that symbol.

  
  

  Common Divisions: In modeling object–oriented systems, the world often gets divided in at least a couple of ways.

  First, there is the division of class and object. A class is an abstraction; an object is one concrete manifestation of that abstraction. In the UML, you can model classes as well as objects, as shown in figure.

  Customer

  Name Address Phone

  
  

  
  

  Elyse

  Jan : Customer

  : Customer

     Graphically, the UML distinguishes an object by using the same symbol as its class and then simply underlying the object’s name.

  
  

  Second, there is the separation of interface and implementation. An interface declares a contract, and an implementation represents one concrete realization of that contract, responsible for faithfully carrying out the interface’s complete semantics. In UML, you can model both interfaces and their implementation, as shown in figure

  Extensibility Mechanisms:  This is not possible for one closed language to ever be sufficient to express all possible nuances of all models across all domains across all time. For this reason, the UML is opened – ended, making it possible for you to extend the language in controlled ways. The UML’s extensibility mechanisms include                    

  ·         Stereotypes

  ·         Tagged values

  ·         Constraints

  
  

         A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building blocks that are derived from existing ones but that are specific to your problem. For example in java language, you will often want to model exceptions. You only want to allow them to be thrown and caught, nothing else. You can make exceptions first class citizens in your models – meaning that they are treated like basic building blocks – by marking them with an appropriate stereotype, as for the class Overflow in figure.

  
  

       A tagged value extends the properties of a UML building block, allowing you to create new information in that element’s specification. For example, you are working on a shrink –wrapped product that undergoes many releases over time; you often want to track the version and author of certain critical abstractions. Version and author are not primitive UML concepts. They can be added building block, such as a class, by introducing new tagged values to that building block. For example, the class EventQueue is extended by marking its version and author explicitly.

  
  

     A constraint extends the semantics of a uml building block, allowing you to add new rules or modify existing ones. For example, you might want to constrain the EventQueue class so that all additions are done in order. As figure shows, you can add a constraint that explicitly marks these for the operation add.

  
  

        Collectively, these three extensibility mechanisms allow you to shape and grow the UML to your project’s needs. These mechanisms also let the UML adapt to new software technology, such as the likely emergence go more powerful distributed programming languages.

  
  

  
  

  3.Architecture:

                          Visualizing, specifying, constructing, and documenting a software – intensive system demands that the system be viewed from a number of perspectives. Different stakeholders – end users, analysts, developers, system integrators, testers, technical writers, and project managers – each bring different agendas to a project, and each looks at that system in different ways at different times over the project’s life. A system’s architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle.

  
  

  Architecture is the set of significant decisions about

  
  

  ·         The organization of a software system

  ·          The selection of the structural elements and their interfaces by which the system is composed

  ·         Their behavior, as specified in the collaborations among elements

  ·         The composition of these structural and behavioral elements into progressively larger subsystems

  ·         The architectural style that guides this organization: the static and dynamic elements and their interfaces, their collaborations, and their composition

     Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic concerns.

  .

  The architecture of a software-intensive system can best be described by five interlocking views. Each view is a projection into the organization and structure of the system, focused on a particular aspect of that system

  
  

   The use case view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. This view doesn’t really specify the organization of a software system. Rather, it exists to specify the forces that shape the system’s architecture. With the uml, the static aspects of this view are captured in use case diagrams; the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.

  
  

    The design view of a system encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users.

  
  

   The process view of a system encompasses the threads and process that form the system’s concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability, and throughput of the system.

  
  

  The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the system’s releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system.