• No results found

Object-Oriented Software Engineering

N/A
N/A
Protected

Academic year: 2021

Share "Object-Oriented Software Engineering"

Copied!
26
0
0

Loading.... (view fulltext now)

Full text

(1)

Object-Oriented Software Engineering

Practical 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 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.

(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.

(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 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

(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

(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.

(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

(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

(9)

Note:

•Be certain to read through and study section Techniques for Making Good Design Decisions.

(10)

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

(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 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.

(12)

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

(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.

(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

(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!!!

(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 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

(17)

Package diagrams*

common

simplechat1 ocsf

client

server

client «imports»

• 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

(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…

(19)

Subsystem Diagrams – a different element*…

requestToRegister(aStudent) : boolean dropCourse(aStudent)

getSchedule( ) : Iterator

Register in a course

Student Actor

Display 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

Classes that encapsulate the required behaviors that are used to ‘realize’ the

‘contract’ (interface)

(20)

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.

(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.

Client <<communication>> Server

(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.

Machine1:

TCP/IP Machine2:

SatelliteGPS

Wireless

communication

Client1:

Client2:

Server:

References

Related documents

This study attempted to establish factors contributing to the use of Letter of credit in international business aspiring to address the objectives which touches on the impact

The corn and wheat treatments were derived from a factorial combination of application dates (October and November), N rates (75 and 100% rate of location N requirements), N

Inflammatory Infiltrates in mPanIN Lesions and mPDAC in K- Ras G12V Expressing Adult Mice Treated with Caerulein for Three Months (A) K-Ras +/G12V.. ;Elas-tTA/tetO-Cre mice were

The research results indicate that the biggest challenge in Tekla‟s online community building is lack of information in the following areas: users‟ needs, community‟s

In December 2004, the Public Health Agency of Canada (PHAC) convened a special meeting of the Advisory Committee on Infection Prevention and Control for Creutzfeldt- Jakob Disease,

to assess the effect of Bloom’s mastery learning approach on 9 th grade students’ academic achievement in different level of cognitive domain i.e., knowledge,

Interviewer note: If the student is or was taking courses in an entirely different field that is or was unrelated to their previous education and that previous education was