1. CSC 480Software Engineering OOAD Process

2. Topics • Overview: OOAD Process • The object model • Identifying classes • Responsibilities and collaborations • Hierarchy: inheritance and aggregation

3. Macro Development Process • The process can be roughly divided into three major phases • Analysis: focusing on what are required • Design: answering the questions of how to fulfill the requirements • Resulting in blueprints that map functional needs to program units (interrelated classes) • Implementation: realizing the design with a working system

4. Down to the Ground-Level Ideas High-up in the air Conceptualization Needs statement Analysis C-req’ts Functional spec (D-req’ts) Design Prototypes Design docs Implementation Solid ground System under dev. System in production

5. Analysis Phase • Specify system needs in a conceptual model • High-level, with details omitted • Document: system requirement specification (SRS) • Completeness • a contract between client and developers • Consistency: without contradiction • Readability: customer & developer (C-&D-) req’ts • Addressing all shareholders interests • Testability: can be tested against reality

6. Requirements Engineering • There is no clear-cut boundary between phases • In OOA process, use cases are a powerful means to present and organize requirements • RUP claims to be use-case-driven • Good for revealing both external and internal needs (user and system requirements) • Can be used for design, implementation, testing, and user training purposes

7. The Design Phase • The goal is to find and present a solution • The key is decomposition • Interrelated classes: class responsibilities collaborations • Focusing on architecture (key classes + interfaces), omitting implementation details • The outcome is system design document (SDD) • Class diagrams • Sequence diagrams • State diagrams

8. Design Phase • Also known as high-level design • Classes at various levels of abstraction • Relationships among classes • Dependency • Inheritance • aggregation • Product design or UI design may be needed • Story-boarding • Screen navigation charts

9. Implementation Phase • Better known as the construction phase • Detail design: sub-class level • Data structures, algorithms • Coding • Unit testing • Gradual integration and repeated “system” testing • Deployment

10. Object and Class • An object is characterized by its • State: • Behavior: • Identity • A class specifies objects with the same behavior • An instance of a class is an object that belongs to the given class

11. Micro Development Process • Largely driven by the stream of scenarios and architectural products • Identifying classes and objects • Identifying semantics of classes and objects • Identifying the relationships among classes and objects • Implementing classes and objects

12. Identifying Classes • A rule of thumb is to look for nouns in SRS • Class candidates usually fall in following categories • Tangible things • Agents • Events and transactions • Users and roles • Systems • System interfaces and devices • Foundational classes

13. Identifying Responsibilities • Responsibilities can be mapped to a functional requirement • Responsibilities include • Things an object need to know: state • Operations an object can perform: behavior • Assign a responsibility to exactly one class • Assign responsibilities as evenly among classes as possible

14. Identifying Relationships • Relationship types • Hierarchical • Inheritance • Aggregation • Association • Dependency: aka collaborations

15. Object Collaborations • An object tends to fulfill its responsibilities by collaborating with other objects • Client-server contract • Client: the object receiving a service • Server: the object providing the service • Contract: the interface definition through which a service may be requested • The client and server roles may change in different collaborations