1 / 15

CSC 480 Software Engineering

CSC 480 Software Engineering. OOAD Process. Topics . Overview: OOAD Process The object model Identifying classes Responsibilities and collaborations Hierarchy: inheritance and aggregation. Macro Development Process. The process can be roughly divided into three major phases

lynley
Télécharger la présentation

CSC 480 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related