Chapter 5 @geoffjuma

Agenda Object Oriented Design Object Oriented Modeling UML CASE tools Use Case Class Diagrams Activity Diagrams Sequence Diagram CASE tools

Introduction OO software development, just like the normal software development process is concerned with designing and developing quality applications using OO tools and processes

Stages in OO Software Development Conceptualization Object-oriented analysis and modeling Object-oriented design Implementation Maintenance

Conceptualization A conceptual model can be defined as a model which is made of concepts and their relationships. A conceptual model is the first step in OO Software Development Life Cycle. It helps to understand the entities in the real world and how they interact with each other.

OO Analysis Now the most important purpose of OO analysis is to: Identifying objects Organizing the objects by creating object model diagram (classes) Defining the internals of the objects, or object attributes (properties) Defining the behavior of the objects, i.e., object actions (behavior) Describing how the objects interact (relationships)

Example: Parking lot system Identify objects Identify behavior of the objects Identify properties of objects Identify relationships Identify classes

Advantages of OOA over Structured Analysis Focuses on data rather than the procedures as in Structured Analysis The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system or external systems It allows effective management of software complexity by the virtue of modularity It can be upgraded from small to large systems at a greater ease than in systems following structured analysis

OO Design In which technology−independent concepts, are mapped onto implementing classes, constraints are identified and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.

Design (contd) Grady Booch (one of the pioneers of OOP) has defined object-oriented design as “a method of design encompassing the process of object- oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”

OO Implementation The principal design of the implementation should directly follow that of the design phase, provided that a OO programming language was selected that supports the OO model of the OO design. It is common to restrict the implementation to a subset of the programming language chosen. This can be useful to ease portability and maintainability.

Software Modeling

What is Modeling? Modeling consists of building an abstraction of reality Abstractions are simplifications because They ignore irrelevant detail They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model

Why Model Software Software is getting increasingly more complex Windows XP > 40 million lines of code A single programmer cannot manage this amount of code in its entirety. Code is not easily understandable by developers who did not write it We need simpler representations for complex systems Modeling is a mean for dealing with complexity

Dynamic vs Static modeling Static Modeling - develops the static structure of the software system in terms of objects. It identifies the objects, the classes and the relationships between the objects. Dynamic Modeling – examines a system's behavior with regards to external changes. Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”.

Dynamic Modeling The dynamic model represents the time– dependent aspects of a system. It is concerned with the temporal changes in the states of the objects in a system. The main concepts are: State, which is the situation at a particular condition during the lifetime of an object. Transition, a change in the state Event, an occurrence that triggers transitions Action, an uninterrupted and atomic computation that occurs due to some event, and Concurrency of transitions.

Systems, Models and Views A system is an organized set of communicating parts A model is an abstraction describing a subset of a system A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting views Views and models of a single system may overlap each other

UML UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML was created by Object Management Group and UML 1.0 specification draft was proposed to the OMG in January 1997. A standardization of other three models namely: Object Modeling Technique, Grady Booch's Method and Object Oriented Software Engineering ISO standardized in 2005

Role of UML in OO design The OO design is transformed into UML diagrams according to the requirement. Before understanding the UML in details the OO concepts should be learned properly. Once the OO analysis and design is done the next step is very easy. The input from the OO analysis and design is the input to the UML diagrams.

UML Elements 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

1. UML Building Blocks The building blocks of UML can be defined as: Things/Entities Relationships Diagrams

1.1 Things Things can be: 1.1Structural 1.1Behavioral 1.1Grouping 1.1Annotational

1.1 Structural Things The Structural things define the static part of the model. They represent physical and conceptual elements that do not change during the system's life span.

Example of Structural Things Following are the brief descriptions of the structural things: Class: represents set of objects having similar responsibilities Interface: defines a set of operations which specify the responsibility of a class. Collaborations: defines interaction between elements. 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.

1.2 Behavioral Things A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things: Interactions: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task. State Machines: 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.

1.3Grouping Things and 1.4 Annotational Things Grouping things can be defined as a mechanism to group elements of a UML model together. Package is the only one grouping thing available for gathering structural and behavioral 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. A note is used to render comments, constraints etc of an UML element.

Structural things - Class A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class is represented using a compartmented rectangle Objects Professor Smith Professor Jones Professor Mellon Attributes Operations

Review: Class Compartments A class is comprised of three sections The first section contains the class name The second section shows the structure (attributes) The third section shows the behavior (operations) In Rose: You may select which compartments are displayed via Diagram Object Properties for the diagram element. You may select which items appear in which compartments using the Edit Compartment function for the diagram element. Professor name empID create( ) save( ) delete( ) change( ) Class Name Attributes Operations Attributes and operations are discussed on subsequent slides. The second and third compartments may be suppressed if they need not be visible on the diagram. While any compartment can be fully suppressed, it can also have some subset of the values showing

Review: Representing Objects An object is represented as rectangles with underlined names : Professor Professor Clark a + b = 10 ProfessorClark Class Name Only ProfessorClark : Professor Classes are discussed in a later slide. The above objects are from a course registration system. Object Name Only Class and Object Name

Structural things - Interface An interface is a collection of operations that specify a service of a class or component. Interfaces support “plug-and-play” architectures Interfaces are not abstract classes, as abstract classes allow you to provide default behavior for some/all of their methods. Interfaces provide no default behavior. Tube Shape Draw Move Scale Rotate <<interface>> Pyramid From the UML User’s Guide (Booch, 1999): An interface is “a collection of operations that are used to specify a service of a class or a component.” Interfaces formalize polymorphism. Interfaces allow us to define polymorphism in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces (e.g., any two “things” which realize the same interface can be said to be polymorphic). You always heard that polymorphism was this big benefit of object orientation, but without interfaces there was no way to enforce it, verify it, or even express it except in informal ways, or language-specific ways. Formalization of interfaces strips away the mystery, and gives us a good way to describe, in precise terms, what polymorphism was trying to do all along. Interfaces are testable, verifiable, and precise. Interfaces are the key to the “plug-and-play-ability” of an architecture: Any classifiers (e.g., classes, subsystems, components) which realize the same interfaces may be substituted for one another in the system, thereby supporting the changing of implementations without affecting clients. Realization relationships are discussed later in this module. Cube Realization relationship

Structural things - Collaboration In the context of a system's architecture, a collaboration allows you to name a conceptual chunk that encompasses both static and dynamic aspects. A collaboration names a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts. You use collaborations to specify the realization of use cases and operations, and to model the architecturally significant mechanisms of your system.

Structural things - Collaboration A collaboration is a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts. A collaboration is also the specification of how an element, such as a classifier (including a class, interface,component, node, or use case) or an operation, is realized by a set of classifiers and associations playing specific roles used in a specific way. Graphically, a collaboration is rendered as an ellipse with dashed lines. Login Login

Structural things – 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 a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name.

Structural things – Component A component is a modular physical part of the system design that hides its implementation behind a set of external interfaces. The implementation of a component can be expressed by wiring together parts and connectors. Graphically, a component is rendered like a class with a special icon in the upper right corner.

Component Example

Structural things – 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. Node #1 <<Node>>

Notations

2. Relationships 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: relationship between two things in which change in one element also affects the other one. Association: is basically a set of links that connects elements of an UML model Generalization: It basically describes inheritance relationship in the world of objects Realization: This relationship exists in case of interfaces

Notations of Relationships

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 Diagrams (cont) Structural Modeling Behavioral Modeling Class and Object diagram Package Diagrams Deployment Diagram Component Diagram Behavioral Modeling Use case diagram Activity Diagrams Sequence diagram