ECE450 Software Engineering II

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