1 / 32

ECE450 Software Engineering II

ECE450 Software Engineering II. Lecture 6 – Object Oriented Design. Goal. To teach you to create good OO designs. What you need: Tools (UML notation) Methods so you know what steps to go through Experience How we will teach you: UML Show you what to do but not how!

marina
Télécharger la présentation

ECE450 Software Engineering II

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. ECE450Software Engineering II Lecture 6 – Object Oriented Design

  2. Goal • To teach you to create good OO designs. • What you need: • Tools (UML notation) • Methods so you know what steps to go through • Experience • How we will teach you: • UML • Show you what to do • but not how! • Next best thing to experience: • Other people’s experience • Design Patterns

  3. Software Design in Context • Requirements • the goals the system needs to satisfy. • Specification • the externally-observable behaviour of the system. • Architecture • the major system-level components • Client, server, database, web interface • their methods of interaction • TCP/IP, shared memory, pipes… • technology used • Language(s) used, XML, SOAP, CORBA • Design • how the job will get done • specify the code that needs to be written.

  4. Software Design is the process of figuring out: • How the classes described in the OOA will be realized in software • How the links and associations should be implemented. • How to leverage existing components • Improving our estimates of cost and time to market • Assessing the prerequisites in terms of labor and infrastructure

  5. The Rationale for doing design • Understanding what will be involved in actually producing the system: • leads to better time and cost estimates, which are essential in commercial software projects • determines prerequisites in terms of labour and infrastructure • By the time you reach design, a lot has already been invested in the project... good design will carry you to success, but bad design will jeopardize the whole project • it is faster and easier to manipulate a program at the design level than to make the equivalent changes in code • work just to change the name of a method in code – change the header, the implementation( s), update all of the callers, etc. • non- trivial changes are much more work! • programmers are human! changes that require code modifications will be avoided, to a fault. • you won't get the best design the first time (maybe not even a good one), so if you discourage change you won't end up with a well designed system

  6. A Good Design Process: • Breaks into phases so progress is measurable. • Is traceable, namely the decisions made during the design can be attributed to particular requirements. • Cheaper than “just doing it”. • Reduces risk compared to “just doing it”. • Accommodates experimentation to explore truly unknown issues. • Supports the setting of reasonable costs and project schedules • Helps avoid “death marches” and wild cost overruns

  7. Object Oriented Design • The process of further describing the classes we will build our system out of in terms of their operations and attributes. • Adding classes that aren’t obviously part of the domain, like abstract classes and interfaces. • Describing how classes make up components.

  8. SystemArchitecture: A A A a a B B B C C C x x D D D f f OOA OOP OOD Where OOD Fits • Design should account for all implementation classes • Augment analysis – additional classes

  9. Output of design is a design document • Prose description • UML • Classes • Associations • Methods • Attributes • Object diagrams • Sequence and collaboration diagrams • Statechart and activity diagrams • Formulae & algorithms • Must relate to the architecture • Can reference the requirements and specification • Must be sufficient to allow coding to commence

  10. Cost vs. Benefit – How much is enough? • should be detailed enough for a competent programmer to build what you envision • you are not the target audience (even if you will be a programmer on the project). You need to get down on paper all those things that make sense in your head. • level of detail can vary depending on the team: • experienced programmers can often make low level design decisions for you • strong teams can resolve minor interface issues themselves • inexperienced teams will need more details • distributed teams (different locations, organizations, time zones, etc) will need more details

  11. Finding Appropriate Objects • Hard part about OOD is decomposing a system into the “right” objects. The right objects: • make the problem easy to solve • cost the least to maintain over the life of the software • Direct sources: • analysis model (you know what that is) • the implementation space (databases, files, UIs, IPC, …) • Additional considerations lead to other classes: • generalize where it makes sense (business sense!) • E.g if you think an algorithm is likely to change add classes to implement a Strategy Pattern

  12. Why OOA first? • OOA class diagrams • divide the problem space into separate highly cohesive pieces (classes) • specify the associations between the pieces • Design • OOA classes are transformed into design class as directly as possible • these classes form the central component for the design • If the central classes are highly cohesive and break down the problem well: • defines the organizing principle for the design • ease of understanding • isolation of changes

  13. OOD OOP Data Design file formats RDBMS schema OODB UI Design unifying concepts screens dialogs Another view of OOA in context OOA Architecture

  14. Assignment 1 – Simplified Design • Assignment 1 simplifies many design issues • no architecture required: • program is monolithic • invocation is via a simple command line • output is simple sequential ASCII • input is excluded from consideration • there is only one operation to perform (plan a release) • To transition from OOA to OOD: • decide how to implement associations • decide how to implement attributes • decide which classes should have which methods • add additional classes for solution-space concepts • command line invocation (some kind of Main class) • file input interface (some kind of DataInput class) • output interfaces and implementation (DataOutput class) • generalizations?

  15. On the border between OOA and OOD • once you have OOA class diagrams and use cases, you can elaborate with sequence diagrams: • sequence diagrams describe how to implement use cases • require operations to be assigned to classes • iterate between these two steps to refine OOA classes

  16. Pick Up From Previous Example • We are asked to build a system for keeping track of the time our workers spend working on customer projects. • We divide projects into activities, and the activities into tasks. A task is assigned to a worker, who could be a salaried worker or an hourly worker. • Each task requires a certain skill, and resources have various skills at various level of expertise.

  17. Steps • Analyze the written requirements • Extract nouns: make them classes • Extract verbs: make them associations • Draw the OOA UML class diagrams • Draw object diagrams to clarify class diagrams • Determine attributes • Determine the system’s use cases • Identify Actors • Identify use case • Relate use cases • Draw sequence diagrams • One per use case • Use to assign responsibilities to classes • Add methods to OOA classes

  18. Use Cases • Actors: • Represent users of a system • human users • other systems • Use cases • Represent functionality or services required by users • Some uses cases will be assisted by the system we build. • Identifying system boundaries.

  19. projectmanager resourcemanager worker systemadministrator Use Case Diagrams Time & Resource Management System(TRMS) ManageResources ManageProjects Log Time <<actor>>BackupSystem AdministerSystem

  20. resourcemanager Resource Manager Use Cases AddSkill FindSkill RemoveSkill <<uses>> <<uses>> UpdateSkill

  21. AddWorker FindWorker RemoveWorker <<uses>> <<uses>> UpdateWorker resourcemanager <<extends>> <<extends>> Assign Skillto Worker Unassign Skillfrom Worker <<uses>> FindSkill More Resource Manager Use Cases

  22. Worker name: string + static Worker findWorker(String name);+ static list of Workers getWorkers(); Add Methods • Read sequence diagrams to identify necessary methods • sequence diagrams identify the messages that pass • between objects • classes will need methods to represent these messages

  23. find worker find skill assign skillto worker find workerby name find skill by name [worker does not currently have skill]assign skill to worker resourcemanager Sequence Diagram – Assign Skill to Worker Use Case Res. Mgr. Win: UI :Worker :Skill :SkillLevel

  24. Worker name: string + static Worker findWorker(String name);+ static int getNWorkers();+ static Worker getWorker(int); In Design • Bring methods closer to implementation • e. g. the worker class needs a “find worker” method, which takes a name as a parameter

  25. (Re)factoring • factoring is the process of assigning responsibilities to classes • because we never get it entirely right the first time, we must also re factor designs, reassigning responsibilities. • e. g. opportunities for reuse via inheritance may become clear after you have identified several subclasses in a hierarchy

  26. OOD: Assigning Methods • For each system use case, draw a sequence diagram • this forces you to decide on operations and assign them to classes • Decide how information is sent and returned • parameters? (yes, most of the time) • global lookup? • helper classes? • Points the way to which attributes and associations are required, and what the navigability of associations ought to be. • record visibility of attributes (public/private/protected) • record navigability of associations

  27. OOD: Implementing Attributes • Decide which OOA attributes will stay in the OOD, and which are not required. • Decide on public/private nature of attributes, and provide an interface for accessing the (conceptually) public attribute. • Decide if attributes are stored as part of the class • some attributes can be computed on demand, or retrieved from external sources (e. g. from a DB or file) • Decide on a type for the attribute: • partly depends on programming language • may need to design new classes for a type • e.g., Date class, or TransformationMatrix class • decide how to implement multiplicities in the language • simple array • Vector type • other

  28. OOD: Implementing Associations • Decide which OOA associations will stay in the OOD, and which are not required. • Decide on navigability • which objects have easy access (usually a reference) to which other objects? • Decide on an interface for accessing associations • adding, removing, traversing links • consistency is desirable • iterators? relationship as a class?, … • Decide how to implement • Does association have an association class? • If so, how will data be stored? • pointers?, store all in some big central lookup dictionary?, … • 1-1 association: embedded data? • 1-*: array or Vector data type? • *-*: need to design something (manager class?)

  29. OOD: Implementing Operations • Most operations will show up in an OOD as methods • In addition methods will be required to modify/access attributes and associations. • How will operations be implemented? • need for additional data members? • e.g., for cached values, to store the state of iterations, … • specify choice of algorithms

  30. Components • The OOA is transformed into the Problem Domain Component of the solution program. • There are many other components required as well • though not so many for assignment #1! • OOA will also form the basis for the design of • input and output file formats • model classes straight into XML elements • persistence design • relational database tables • OODB • UI

  31. Components of the Solution • The precise set of components is architecture dependent • Problem Domain Component • a.k.a. the Domain Object Model for the application • Data Management Component • how will data be input into the system? • how will modified data be saved back and under what conditions? • how will transactions (if required) be done? • does design need to be re-targetable to other data back-ends? • Reporting Component • how will report data be gathered and output? • Task Management Component • how will commands be invoked? • and possibly undone? • concurrency • Human Interaction Component • how will the user interface interact with the rest of the program? • Re-targetable? • IPC (Inter-Process Communications) Component • how will this tier of the solution interact with other tiers?

  32. Elements of the Problem Domain Component • Reuse design and programming classes. • Group problem-domain-specific classes and establish a protocol by adding generalization classes. • Accommodate inheritance limitations in implementation language. • Add design classes • Associations • Run-time modifiability • … • Improve performance • Speed, memory, perceived speed • Support the data management component

More Related