Object-Oriented Software Engineering Practical Software Development using UML and Java Architecting and Designing Software Chapter 9 in OOSE Textbook plus.

Slides:



Advertisements
Similar presentations
Distributed Data Processing
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Deliverable #8: Detailed Design - Overview due: Wednesday, 7 March All Deliverable materials are to be posted into Team Concert. Your to.
Software Engineering 2003 Jyrki Nummenmaa 1 OBJECT ARCHITECTURE DESIGN These slides continue with our example application, based on the simplified.
Alternate Software Development Methodologies
9.5 Software Architecture
1 Layers Data from IBM-Rational and Craig Larman’s text integrated into these slides. These are great references… Slides from these sources have been modified.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Technical Architectures
Introduction To System Analysis and Design
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software1 Layers Data from IBM-Rational and Craig Larman…
The Architecture Design Process
CS CS 5150 Software Engineering Lecture 13 System Architecture and Design 1.
Use Case Analysis – continued
System Architecture: Desing alternatives and methodologies.
Course Instructor: Aisha Azeem
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
What is Software Architecture?
Objectives Design Class Diagrams Issues in system design Generalization Review UML papers.
CS 4310: Software Engineering
Chapter 10 Architectural Design
The Design Discipline.
Design COP 3538 Summer © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 2 The Process of Design Definition: – Design is.
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture # 17 Good Software Design SWE 316: Software Design and Architecture.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
UML Unified Markup Language Ziya Karakaya Atılım University, Computer Engineering
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
What is Enterprise Architecture?
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
An Introduction to Software Architecture
CSE 303 – Software Design and Architecture
9.4 Software Architecture
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
GRASP: Designing Objects with Responsibilities
Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
TAL7011 – Lecture 4 UML for Architecture Modeling.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Object-Oriented Software Engineering Practical Software Development using UML and Java Architecting and Designing Software Chapter 9 in OOSE Textbook plus.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
CSC480 Software Engineering Lecture 10 September 25, 2002.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
UML (Unified Modeling Language)
UML - Development Process 1 Software Development Process Using UML.
CS223: Software Engineering Lecture 13: Software Architecture.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Introduction. System Design Hardware/Software Platform Selection Software Architectures Database Design Human-Computer Interaction (HCI) Interface Object.
Two New UML Diagram Types Component Diagram Deployment Diagram.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
And Some UML Diagrams in between
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Analysis models and design models
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Designing Software.
Design Yaodong Bi.
Logical Architecture & UML Package Diagrams
Presentation transcript:

Object-Oriented Software Engineering Practical Software Development using UML and Java Architecting and Designing Software Chapter 9 in OOSE Textbook plus Almost all taken directly from textbook – often verbatim.  Finish Process + Software Architecture Architectural Patterns

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software2 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 increase reusability; 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software3 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software4 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 cohesion of 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…)

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software5 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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software6 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software7 Design Principle 10: Design for Testability Take steps to make testing easier Design a program to automatically test the software —Discussed more in Chapter 10 —  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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software8 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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software9 Note: Be certain to read through and study section 9.3 Techniques for making good design decisions.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software Techniques for making good design decisions Using priorities and objectives to decide among alternatives Step 1: List and describe the alternatives for the design decision. Step 2: List the advantages and disadvantages of each alternative with respect to your objectives and priorities. —Prior to starting a design effort, main objectives and ‘priorities’ should be made clear. —Objectives need to be measurable; priorities are used when compromised must be made (e.g. Non-functional requirements and a host of other examples… Step 3: Determine whether any of the alternatives prevents you from meeting one or more of the objectives. —If non prevent us from accomplishing the objectives… —If ALL prevent… Step 4: Choose the alternative that helps you to best meet your objectives. Step 5: Adjust priorities for subsequent decision making.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software11 Example priorities and objectives Imagine a system has the following objectives, starting with top priority: Security: Encryption must not be breakable within 100 hours of computing time on a 400Mhz Intel processor, using known cryptanalysis techniques. Maintainability. No specific objective. CPU efficiency. Must respond to the user within one second when running on a 400MHz Intel processor. Network bandwidth efficiency: Must not require transmission of more than 8KB of data per transaction. Memory efficiency. Must not consume over 20MB of RAM. Portability. Must be able to run on Windows 2000, NT 4 and ME as well as Linux

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software12 Example evaluation of alternatives ‘NO’ means that the objective is not met

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software13 Using cost-benefit analysis to choose among alternatives To estimate the costs, add up: —The incremental cost of doing the software engineering work, including ongoing maintenance —The incremental costs of any development technology required —The incremental costs that end-users and product support personnel will experience —Incremental costs refers to the extra costs involved if this option is selected. —“The software engineering cost is proportional to the amount of time spent by software engineers, commonly measured in person-days or person-months. Most organizations convert this into monetary terms by multiplying by a factor that accounts for the average salary plus other costs associated with employing a person, such as their office space.” p. 322 To estimate the benefits, add up: —The incremental software engineering time saved —The incremental benefits measured in terms of either increased sales or else financial benefit to users

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software  Software Architecture*  Software architecture is process of designing the global organization 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software15 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 global organization 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software16 Contents of a good architectural model* A system’s architecture will often be expressed in terms of several different views that 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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software17 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software18  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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software19 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 – (Chapter 3 later) 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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software20 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 high level to indicate software components and their interfaces  Use cases provide a good summary from the perspective of the user; class diagrams show the services provided by components (subsystems…) and the main data that is stored; interaction diagrams 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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software21 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).

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software22 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…

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

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software24 Subsystem Design – much more… Subsystems have a more formal structure – parts, the operations (we call this the Interface; e.g. signatures…) The specification elements (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.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software25 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, …) ClientServer >

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software26 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. Machine1: TCP/IP Machine2: GPS Satellite Wireless communication Client1: Client2: Server: