Object-Oriented Software Engineering Practical Software Development using UML and Java

1. Object-Oriented Software EngineeringPractical Software Development using UML and Java Architecting and Designing Software  Finish Process + Software Architecture Architectural Patterns

2. Design Principle 5: Increase Reusability where possible • Design the various aspects of your system so that they can be used again in other contexts • Goal is to increasereusability; secondly actively reuse the work of others. (for example: think ‘application layer’ and ‘domain layer’) • Generalize your design as much as possible • Layers, packages, subsystems help greatly! • Some address the GUI; some business services; … • Design your system to contain hooks • (Will discuss in Frameworks.) But essentially this means to design your system where some things are provided, but can be modified. Others must be added… • Simplify your design as much as possible • Divide and conquer; low coupling; high cohesion… • Separation of ‘concerns’ (subsystems, packages) etc. Chapter 9: Architecting and designing software

3. Design Principle 6: Reuse Existing Designs and Code where Possible • Design with Reuse is complementary to Design for Reusability • Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components • Cloning should not be seen as a form of reuse • If you need several lines of code, then encapsulate and call if from where it may be needed. Chapter 9: Architecting and designing software

4. Design Principle 7: Design for Flexibility • These are particularly good!! • Actively anticipate changes that a design may have to undergo in the future, and prepare for them • Reduce coupling and increase cohesionof design elements • Create abstractions like interfaces or super classes. • Readily supports extensions and polymorphism • Do not hard-code anything • Remember, programming is the realization of design!!! • Leave all options open • Do not restrict the options of people who have to modify the system later • Use reusable code and make code reusable(where practical…) Chapter 9: Architecting and designing software

5. Design Principle 8: Anticipate Obsolescence • Plan for changes in the technology or environment so the software will continue to run or can be easily changed •  Avoid using early releases of technology • NEVER a good idea to use unproven technologies… • Avoid using software libraries that are specific to particular environments – may not be supported in the future… • Avoid using undocumented features or little-used features of software libraries •  Avoid using software or special hardware from companies that are less likely to provide long-term support • Use standard languages and technologies that are supported by multiple vendors Chapter 9: Architecting and designing software

6. Design Principle 9: Design for Portability • Have the software run on as many platforms as possible • Avoid the use of facilities that are specific to one particular environment e.g. a library only available in Microsoft Windows • Remember: we develop systems that will hopefully be used ‘for a long time.’ Platforms change! • More and more technologies are here and coming along which support portability very nicely…. • Be aware of these in your design decisions / choices. • We’d rather not care (usually) how many bits there are in an integer or key definitions that only apply in a special environment. Chapter 9: Architecting and designing software

7. Design Principle 10: Design for Testability • Take steps to make testing easier • Design a program to automatically test the software  Ensure that all the functionality of the code can by driven by an external program, bypassing a graphical user interface  In Java, you can create a main() method in each class in order to exercise the other methods Chapter 9: Architecting and designing software

8. Design Principle 11: Design Defensively • Never trust how others will try to use a component you are designing • Handle all cases where other code might attempt to use your component inappropriately • “Robustness” – Discuss tradeoffs and criticality… • Check that all of the inputs to your component are valid: the preconditions • Unfortunately, over-zealous defensive design can result in unnecessarily repetitive checking Chapter 9: Architecting and designing software

9. Note: • Be certain to read through and study section Techniques for Making Good Design Decisions. Chapter 9: Architecting and designing software

10. Software Architecture •  Software architecture is process of designing the globalorganization of a software system, including: • Dividing software into subsystems. • Deciding how these will interact. • Determining their interfaces. • The architecture is the core of the design, so all software engineers need to understand it. • The architecture will often constrain the overall efficiency, reusability and maintainability of the system. (and this is very good!) • Suitable architectural choices often impact or address a number of the non-functional requirements of an application. Chapter 9: Architecting and designing software

11. The Importance of Software Architecture • Why you need to develop an architectural model: • To enable everyone to better understand the system • Particularly true for large, distributed, complicated systems • To allow people to work on individual pieces of the system in isolation • To prepare for extension of the system • To facilitate reuse and reusability • Software architecture is the process of designing the globalorganization of a system, including breaking up the system into subsystems, deciding how these will interact, and determining their interfaces. • The documentation of all this is called the architectural model. Chapter 9: Architecting and designing software

12. Contents of a good Architectural Model • A system’s architecture will often be expressed in terms of several different viewsthat are high level. • The logical breakdown into subsystems • e.g. packages with interfaces • The interfaces among the subsystems • The dynamics of the interaction among components at run time • Often shown by interaction diagrams (sequence and collaboration) • May be shown via state diagrams for objects with sufficient state complexity – especially true in the scientific / engineering community. • The data that will be shared among the subsystems • Usually shown by class diagrams • The components that will exist at run time, and the machines or devices on which they will be located • Usually shown on component / deployment diagrams Chapter 9: Architecting and designing software

13. Design Stable Architecture • To ensure the maintainability and reliability of a system, an architectural model must be designed to be stable. • Being stable means that the new features can be easily added with only small changes to the architecture • That is, it must be flexible such that new features do not / minimally impact existing architectural components. Chapter 9: Architecting and designing software

14.  Developing an Architectural Model • Start by sketching an outline of the architecture • Based on the principal requirements and use cases •  Determine the main components that will be needed • Databases; main software subsystems; specific hardware/software, if needed; •  Choose among the various architectural patterns • Discussed in the next lecture. • Requires understanding of architectural layers, modules, and a number of related options… • Suggestion: have several different teams independently develop a first draft of the architecture and merge together the best ideas Chapter 9: Architecting and designing software

15. Developing an Architectural Model • Refine the architecture • Identify the main ways in which the components will interact and the interfaces between them • Note that these are ‘abstractions’ and ‘interfaces’ and NOT implementations. •  Decide how each piece of data and functionality will be distributed among the various components • Needed for traceability •  Determine if you can re-use an existing framework, if you can build a framework • Consider each use case and adjust the architecture to make it realizable • Remember, the RUP is use-case driven!!! • Mature the architecture as you develop the ‘final’ class diagrams and the interaction diagrams. Chapter 9: Architecting and designing software

16. Describing an Architecture using UML • All UML diagrams can be useful to describe aspects of the architectural model • Remember, this is to be done at a highlevel to indicate software components and their interfaces •  Use casesprovide a good summary from the perspective of the user; class diagramsshow the services provided by components (subsystems…) and the main data that is stored; interactiondiagrams show the main protocols used when components interact with each other. • Four UML diagrams are particularly suitable for architecture modelling: • Package diagrams • Subsystem diagrams • Component diagrams • Deployment diagrams Chapter 9: Architecting and designing software

17. Package diagrams* • A Package is a group of model elements placed together because they are logically related. • A Java package is only a collection of classes. But this ‘can’ be a package in UML and we use this as an example. Here, the packages contain other packages. Packages can contain anything… • Of course, developing such a package means we should subscribe to ensuring that the elements exhibit cohesion and coupling. • Cohesion  (high) that the contents contains elements that are closely related in some way • Provide a capability all of which classes contribute to this capability, or what have you. • Coupling  (low) decrease the number of dependencies of its model elements. Provides for replacement of components with minimal impact (preferably none). Chapter 9: Architecting and designing software

18. Package Diagrams – More* • Can have dependencies among packages. • Means one or more elements in one package depends in some way on at least one element in another package (e.g. a class in one package depends on a class (object…) in another package. Hence there is a dependency between these two packages… • Indicated by the dashed arrow with open triangle. • We have been saying this is ‘realization’ and that the dependency symbol is a dashing line with an arrow, as in • If you use a package, you must also have access to any other packages that ‘it’ depends upon. Can be significant. • With lots of dependencies, packages may be difficult to reuse, in that we would need access to all of the elements. • We would also want to make the interface to the package as simple as possible to facilitate reuse. • Use the Façade pattern (see chapter on Design Patterns) to facilitate the interface – later. • Note the preceding slide’s graphic of a package… Chapter 9: Architecting and designing software

19. Registration Student Subsystem Diagrams – a different element*… These authors like the upside down fork to indicate a subsystem. I prefer the clearly-shown interface class. Realization Elements requestToRegister(aStudent) : boolean interface dropCourse(aStudent) CourseSection * * * * * getSchedule( ) : Iterator Specification Elements Classes that encapsulate the required behaviors that are used to ‘realize’ the ‘contract’ (interface) * Register in a course * Drop a course Student Actor Display Digest this page. schedule Some/parts of these use cases /scenarios may be address by this subsystem Chapter 9: Architecting and designing software

20. Subsystem Design – much more… • Subsystems have a more formal structure – parts, • the operations (we call this the Interface; e.g. signatures…) • The specificationelements (like a use case diagram), and a • Realization elements (class diagram or interaction diagram) • Recall the mappings from the realization elements to the Interface (specification). • Here, some elements of a Use Case are modeled. Chapter 9: Architecting and designing software

21. Component diagrams Show how physical components relate to each other. files, dlls, exes, … Relationships exist between components in many ways. Distinguish between Packages and Components. Packages are logical groupings of design elements; normally considered during design; groupings of related elements Components show relationships between physical components. often (not always!) used to show executables; can be used to merely show physical relationships or even ‘place.’ (databases; GUIs; .exe, …) <<communication>> Client Server Chapter 9: Architecting and designing software

22. Deployment diagrams Show the hardware where various instances of components reside at run time. Nodes in deployment diagrams represent computational units, like a computer, device, Links are normally shown to illustrate how these components communicate with each other. But even the links (at this time) may be not locked in. Wireless Machine1: Machine2: GPS communication TCP/IP Satellite Client1: Server: Client2: Chapter 9: Architecting and designing software