Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN “Time is a great teacher, but unfortunately it kills all its pupils.” - Hector Berlioz Objectives Describe the book goals and scope Define OOA/D (Object-Oriented Analysis and Design) Illustrate a brief OOA/D example Overview UML and visual agile modeling

Applying UML and Patterns Larman’s book is a tool to help developers/students learn core skills in OOA/D. These skills are essential for the creation of well- designed, robust, and maintainable software using OO technologies and languages such as Java or C#. Knowing an object oriented language is necessary but insufficient first step to create object systems. Knowing how to “think in objects” is critical ! Owning a hammer doesn’t make one an architect” (Proverb) r

Fig. 1.1 Topics and skills covered in the book. UML notation Requirements analysis Principles and guidelines Patterns Iterative development with an agile Unified Process OOA / D The book illustrates this in the context of long-running case studies that evolve over several iterations.

Analysis Analysis emphasizes an investigation of the problem and requirements, rather than a solution. In software development, we are primarily concerned with two forms of analysis. Requirements Analysis is discovering the requirements that a system must meet in order to be successful. Object-Oriented Analysis is investigating the objects in a domain to discover information important to meet the requirements. r

Use Cases Writing Use Cases is not a specifically OO artifact – they are simply written stories. However, they are a best practice for elaborating and understanding requirements. r

Design Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. Design ideas often exclude low-level or obvious details – obvious to the intended consumers. There are subsets of design, including architectural design, object design, database design. Do the right thing (analysis), and do the thing right (design). r

Object-Oriented Analysis and Design (OOA/D) During OOA, the emphasis is on finding and describing the objects (or concepts) in the problem domain, i.e., domain objects. During OOD (or simply object design), the emphasis is on defining software objects and how they collaborate to fulfill the requirements. During OOP (OO Programming) or Implementation, design objects are implemented in a programming language. Implementation is also known as Coding or Construction. r

Fig. 1.2 Object-orientation emphasizes representation of objects

Responsibility-Driven Design It is the classical OO design metaphor(symbol) The most important skill in OOA/D is assigning responsibilities to objects. That determines how objects interact and what classes should perform what operations. r

Design Patterns Certain tried-and-true solutions to design problems have been expressed as principles of best practice, often in the form of Design Patterns. A Design Pattern is a named problem solution formula that apply excellent design principles. r

The Unified Process (UP) A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development. Requirements analysis and OOA/D needs to be presented and practiced in the context of some development process. Here, an agile (light, flexible) approach to well-known Unified Process (UP) is used as a sample iterative development process. r

Unified Modeling Language (UML) UML is the de facto standard diagramming notation for drawing or presenting pictures related to OO software. UML is a visual language for specifying, constructing and documenting the artifacts of OO systems. Knowing UML helps you communicate with others in creating software. r

Three ways people apply UML are ... UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space Agile modeling emphasizes UML as sketch. UML as blueprint relatively detailed design diagrams used either for reverse engineering to visualize and better understand existing code, or for forward engineering to guide for code generation, either manually or automatically with a tool. UML as a programming language Complete executable specification of a sw system in UML. r

Three perspectives to apply UML are ... Conceptual perspective – the diagrams are interpreted as describing things in a situation of the real world or domain of interest. Specification (software) perspective – the diagrams describe sw abstractions or components with specifications and interfaces, but no commitment to a particular language implementation. Implementation perspective – the diagrams describe sw implementations in a particular technology. r

Fig. 1.6 Different perspectives with UML In practice, most software-oriented UML diagramming assumes an implementation perspective and the specification perspective is often used for design. r