Object Oriented Modeling and Design Reference Books 1

Object Oriented Modeling and Design Reference Books: 1. Grady Booch, James Rumbaugh, Ivar Jacobson “Unified Modeling Language User Guide”, Addison. Wesley 2. Rambaugh, “Object Oriented Modeling and Designing”. PHI 3. Bouch. “Object Oriented Analysis and Design with Applications”. Addison Wesley. 4. Dan Pilone, Neil Pitman “UML 2. 0 in a Nutshell”, O'Reilly 5. Schah, “Introduction to OOAD with UML and Unified Process”, TMH

UNIT-I

NEW PARADIGMS • Object –oriented mean: üOrganize s/w as a collection of discret objects that incorporate both data structure & behavior üAn object is a concept, abstraction, or thing with sharp boundaries and meaning for an application üobject is something that has: -State -Behavior - Identity • characteristic of object: 1. identity: ü Data is quantize into discrete , distinguishable entity called object ü Ex: - window, car 2. Classification : What is CLASS? ü ü a collection of objects that share common properties, attributes, behavior and semantics, in general. A collection of objects with the same data structure (attributes, state variables) and behavior (function/code/operations) in the solution space.

ü ü A blueprint or definition of objects. A factory for instantiating objects. The description of a collection of related components. Classification – Grouping of common objects into a class Ex: - fruit • Polymorphism: ü ü The ability to hide many different implementations behind a single interface Same operation may behave differently on different classes Operation is an action or transfer that an object perform Specific implementation of an operation by a certain class is called method • Inheritance : ü Automatic duplication of super class attribute and behavior definitions in subclass. ü Sharing of attribute & operation among classes based on hierarchical relationship

What is Object-Orientation - Example of Abstraction and Encapsulation Class Car Attributes q Model q Location Operations q Start q Accelerate Lawrence Chung CS 6359. OT 1: Module 1 5

Object –oriented thinking and rethinking • Identification & organization of application domain concept rather than their final representation in a programming language 1. modeling concept only , not implementation • Most focus on programming language implementation issues rather than analysis and design object • OO is not a programming technique • Express concept clearly & communicate between developer and customer 2. object – oriented methodology: • Methodology consist building a model of an application domain & then adding implementation detail to it during design of a system , it’s known as object – modeling technique (OMT) • Steps: 1. Analysis: -build a model of real-world situation sowing it’s important properties - Understand the problem statement - Object in model is application domain concept , not computer implementation

2. System design: -make higher level decision about overall architecture - Target system is organized into subsystem based on analysis structure &proposed architecture 3. Object design: - Build design model based on analysis model but contain implementation detail - Focus on data structure & algorithm needed to implement each class 4. Implementation : - Object classes & relationships of object design are translated into a particular programming language , d/b & h/w implementation

Object Modeling Technique (OMT) • It is an object-oriented analysis, design, and implementation methodology that focuses creating a model of objects from the real world and then using this model to develop object-oriented software. • OMT methodology uses three kinds of models to describe a system: 1. Object model - describes the objects in the system and their relationships; 2. Dynamic model - describes the interactions among objects in the system; and 3. Functional model - describes the data transformations of the system. - Object model components: • Object: - An object is a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand. - All objects have identity and are distinguishable. • objects can belong to more than one class.

§ Object –Oriented Themes 1. Abstraction • focus on essential properties, ignore unimportant details 2. Encapsulation • separate external, visible behavior from internal, hidden behavior 3. Combining data and behavior • objects, not developers, decide how to carry out operations 4. Sharing • similar operations and structures are implemented once. 5. Emphasis on object-structure rather than procedure structure • behavior more stable than implementation

Modeling • When you make a model you are making a mapping from the problem domain to a representation of the system you are modeling. Reality System • When you work object-oriented the model tends to be close to the system modeled, and a program execution can be regarded as a simulation of the behavior of the system. Itntroduction to UML, page 10

Why Do We Model? • Models give us a template that guides us in constructing a system. • If you want to make a building you first make a blueprint of the building to make, in the same way you should make a model of the system you want to make. As the complexity of systems increases, so does the importance of good modeling techniques. • Models help us visualize a system at different levels of abstraction, this makes it easier to manage complexity and to understand the system. • We build models so that we can better understand the system we are developing. Itntroduction to UML, page 11

§ The Importance of Modeling • A model is a simplification of reality. • A model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30, 000 -foot view of the system under consideration. • A good model includes those elements that have broad effect and omits those minor elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. • A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.

1. Models help us to visualize a system as it is or as we want it to be. 2. Models permit us to specify the structure or behavior of a system. 3. Models give us a template that guides us in constructing a system. 4. Models document the decisions we have made. • We build models of complex systems because we cannot cover such a system in its entirety.

§ Principles of Modeling 1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Choose your models well. The right models will brilliantly illuminate the most wicked development problems, offering insight that you simply could not gain otherwise; the wrong models will mislead you, causing you to focus on irrelevant issues. 2. Every model may be expressed at different levels of precision. 3. The best models are connected to reality. 4. No single model is sufficient. Every nontrivial system is best approached through 5. a small set of nearly independent models.

§ Object-Oriented Modeling • In software, there are several ways to approach a model. The two most common ways are from an algorithmic perspective and from an object-oriented perspective. • The traditional view of software development takes an algorithmic perspective. In this approach, the main building block of all software is the procedure or function. This view leads developers to focus on issues of control and the decomposition of larger algorithms into smaller ones • The contemporary view of software development takes an object-oriented perspective. • In this approach, the main building block of all software systems is the object or class. Simply put, an object is a thing, generally drawn from the vocabulary of the problem space or the solution space; • a class is a description of a set of common objects. Every object has identity (you can name it or otherwise distinguish it from other objects), state (there's generally some data associated with it), and behavior (you can do things to the object, and it can do things to other objects, as well).

Architecture of UML (4+1 view) • 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. • system's architecture 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. • 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.

• use case view - It 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 - the static aspects of this view are captured in use case diagrams the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams. • design view it 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. - With the UML, the static aspects of this view are captured in class diagrams and object diagrams - the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

• process view - It encompasses the threads and processes that form the system's concurrency and synchronization mechanisms. - This view primarily addresses the performance, scalability, and throughput of the system. - With the UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes. • implementation view - It encompasses the components and files that are used to assemble and release the physical system. - This view 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. - With the UML, the static aspects of this view are captured in component diagrams the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

• deployment view - It encompasses the nodes that form the system's hardware topology on which the system executes. - This view addresses the distribution, delivery, and installation of the parts that make up the physical system. - the static aspects of this view are captured in deployment diagrams - the dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

RUP (Software Development Life Cycle) • What is RUP • A software development approach that is iterative, architecture-centric and use-case driven • RUP is process independent meaning that it is not tied to any particular software development life cycle. 1. Use case driven 2. Architecture-centric 3. Iterative and incremental • • • Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing, and for communicating among the stakeholders of the project. Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. iterative process is one that involves managing a stream of executable releases , each new release is focused on attacking and reducing the most significant risks to the success of the project.

• Iterative Development Phases: Inception: Understand what to build – Vision, high-level requirements, business case – Not detailed requirements Elaboration: Understand how to build it Construction: Build the product Transition: Validate solution – Baseline architecture, most requirements detailed – Not detailed design – Working product, system test complete – Stakeholder acceptance

As An Effective Process, the RUP: • Provides guidelines for efficient development of quality software – Provides suggested flows of activities and assignment of roles to artifacts • Reduces risk and increases predictability – Through iteration planning, risks aggressively attacked up front • Captures and presents best practices – very detailed. – Learn from other’s experiences – The RUP is huge! Configurable to the project; . – Contains disciplines – addressing all stakeholder concerns • Provides roadmap for applying tools – it is NOT just a theory – Suggests activity sequences; – Adaptable for large and small projects. • The RUP is a use-case driven, architecture-centric, iterative development process!

C O N T E N T S T R U C T U R E TIM E

Inception: Know What to Build • Prepare vision document and initial business case – Include risk assessment and resource estimate • Develop high-level project requirements – Initial use-case and domain models (10 -20% complete) • Manage project scope – Reduce risk by identifying all key requirements – Acknowledge that requirements will change • Manage change, use iterative process

Elaboration: Know How to Build It • Detail requirements as necessary (~80% complete) – Less essential requirements may not be fleshed out • Produce an executable and stable architecture – Define, implement and test interfaces of major components – Identify dependencies on external components and systems. Integrate shells/proxies of them. – Some key components will be partially implemented – Roughly 10% of code is implemented. • Drive architecture with key use cases – 20% of use cases drive 80% of the architecture – Design, implement and test key scenarios for use cases • Verify architectural qualities – Reliability: Stress test – Scalability and Performance: Load test • Continuously assess business case, risk profile and development plan

Construction: Build The Product • Complete requirements and design model • Design, implement and test each component – Prototype system and involve end users – Incrementally evolve executable architecture to complete system • Build daily or weekly with automated build process • Test each build – Automate regression testing – Load and stress test to ensure architectural integrity • Deliver fully functional software (beta release) – Includes training material, user and deployment documentation • Produce release descriptions

Transition: Deploy to End Users • Produce incremental ‘bug-fix’ releases • Update user manuals and deployment documentation • Update release descriptions • Execute cut-over • Conduct “post-mortem” project analysis

Development Cycles Going through the four major phases is called a development cycle, and it results in one software generation. The first pass through the four phases is called the initial development cycle. Unless the life of the product stops, an existing product will evolve into its next generation by repeating the same sequence of inception, elaboration, construction, and transition phases. This is the evolution of the system, so the development cycles after the initial development cycles are its evolution cycles. • Process Workflows The Rational Unified Process consists of nine process workflows. 1. Business modeling Describes the structure and dynamics of the organization 2. Requirements Describes the use case— based method for eliciting requirements 3. Analysis and design Describes the multiple architectural views 4. Implementation Takes into account software development, unit test, and integration 5. Test Describes test cases, procedures, and defect-tracking metrics 6. Deployment Covers the deliverable system configuration 7. Configuration management : Controls changes to and maintains the integrity of a project's artifacts 8. Project Management Describes various strategies of working with an iterative process 9. Environment Covers the necessary infrastructure required to develop a system • Artifacts Each Rational Unified Process activity has associated artifacts, either required as an input or generated as an output. Some artifacts are used to direct input to subsequent activities, kept as reference resources on the project, or generated in a format as contractual deliverables. •

• Models are the most important kind of artifact in the Rational Unified Process. A model is a simplification of reality, created to better understand the system being created. In the Rational Unified Process, there are nine models that collectively cover all the important decisions that go into visualizing, specifying, constructing, and documenting a softwareintensive system. 1. Business model Establishes an abstraction of the organization 2. Domain model Establishes the context of the system 3. Use case model Establishes the system's functional requirements 4. Analysis model (optional)Establishes an idea design 5. Design model Establishes the vocabulary of the problem and its solution 6. Process model (optional) Establishes the system's concurrency and synchronization mechanisms 7. Deployment model Establishes the hardware topology on which the system is executed 8. Implementation model Establishes the parts used to assemble and release the physical system 9. Test model Establishes the paths by which the system is validated and verified

• Other Artifacts The Rational Unified Process's artifacts are categorized as either management artifacts or technical artifacts. The Rational Unified Process's technical artifacts may be divided into four main sets. 1. Requirements set Describes what the system must do 2. Design set Describes how the system is to be constructed 3. Implementation set Describes the assembly of developed software components 4. Deployment set Provides all the data for the deliverable configuration