| Contents (hide) 1 Objectives 1.1 Design vs. Implementation 1.2 Modularity 1.3 Object Oriented Analysis 2 Introductory case study: the Library 2.1 The Problem 2.2 Use case model 2.3 Scope and interactions 2.4 Identifying Concepts 2.5 Relations Between Concepts 2.6 The system in action |
Objectives
This lecture introduces basic concepts of Object Oriented Design (OOD) and explains how they are necessary to a proper understanding of modern Runtime Environments (RTE):- What is a high-quality software system
- How to build high-quality systems
- Design vs. Implementation
The quality of software is measured by the following criteria:
- Usability/Usefulness
- Reliability
- Flexibility
- Affordability
- Availability
Which means our software must be:
- Useful - Must define Requirements
- Reliable - Must define and verify Invariants, Pre and Post Conditions
- Flexible, Affordable - Must use Encapsulation, Modularity, Reusable code
- Affordable - Must reuse existing components, must use efficient code
Design vs. Implementation
Software Design does not determine how code will be implemented but how it will be organized in components, how components will be interfaced logically (not physically), how components fulfill given requirements. Special languages have been defined to specify software at this level of abstraction (as opposed to programming languages). The most used one is called UML (Unified Modelling Language).Modularity
The main objective of design is to preserve modularity among components. Several criteria exist to measure modularity:- Plugability: possibility to add a component in a design independently of other requirements.
- Low coupling: low level of dependency among components.
- High cohesion: each component is only responsible for a single task.
An "Architecture" is a set of related components fulfilling together a given requirement. The RTE provides a set of architectures to manage processes and concurrency, storage, communication.
Object Oriented Analysis
The process of analysis of a problem to be implemented is the following:- Use case scenarios
- Identify objects (entities in the real world, carrying identity)
- Identify behavior of objects: defines interfaces and polymorphism
- Define a software architecture: set of interfaces, and their mapping to classes.
Introductory case study: the Library
(From Using UML, Stevens and Pooley, Updated Edition, 2000, Addison Wesley, Chapter 3.)The Problem
You have been contacted to develop a computer system for a university library. After some careful investigation, the following facts emerge about the requirements that an ideal system should satisfy:- Books and journals
The library contains books and jornals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of stuff may borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current year's journals are sent away to be bound into volumes at the end of each year. - Borrowing
The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above. The system should produce reminders when a book is overdue. There may in the future be a requirement for users to extend the loan of a book if it is not reserved. - Browsing
The system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not, to reserve the book. Anybody can browse in the library.
Note that it is still not clear what the different tasks are or who needs what …
Use case model
If a system is to be seen as having high quality, it must meet the needs of its users. So we take a user-oriented approach to systems analysis. We identify the users of the system and the tasks they must undertake with the system. What do we mean by "users" and "tasks"? UML in fact uses as technical terms actors and use cases. An actor is a user of the system in a particular role. (In fact an actor can also be an external system which is like a user from the point of view of our system: the crucial point is that it's someone or something external to the system we're designing, which interacts with our system and can place demands on our system.) For example, our system will have an actor BookBorrower representing the person who interacts with the system to borrow a book. It's not clear to us whether it is a library member, or it is a librarian acting on behalf of a library member, but for our present purposes we don't need to know. A use case is a task which an actor needs to perform with the help of the system, such as Borrow copy of book. At this point we can record the information pictorially, is a use case diagram for the system:
Scope and interactions
Now we have a reasonable clear idea of what an ideal system would do. However, experience have shown that the "big bang" single-release approach to systems building, in which the developers aim to deliver an ideal system in their first and only delivery, is extremely risky. To limit the risks, it is better to aim to get to the ideal system in several steps or iterations. The first iteration results in the delivery of a system with only the most basic and essential functionality; later iterations enhance the system. One of the main purposes of use cases is to help identify suitable dividing lines between iterations: an iteration can deliver enough of the system to allow certain use cases to be carried out, but not others. In this case, let us suppose that (after discussing priorities with the customer) we decide that the first iteration of the system should provide the use cases:- Borrow copy of book
- Return copy of book
- Borrow journal
- Return journal
Here the limited use case diagram for the first iteration of our system, and a brief restatement of the requirements of the first iteration, discarding irrelevancies:
Identifying Concepts
Identifying the right concepts is one of the main skills of object oriented development. It is crucial for building extensible software and to facilitate code reuse. We start the process of identifying concepts using the noun identification technique. Take a statement of requirements of the system and underline its nouns and noun phrases; that is, identify the words and phrases denoting things:- Books and journals. The library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of stuff may borrow up to 12 items at one time.
- Borrowing. The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above.
Add more concepts looking for known categories. For example: Physical objects, Places, Transactions, Roles of people, Containers of other things, Specifications designs or description of things, Events, Catalogs. This gives a list of candidate concepts, which we can then reduce and modify to get our initial class list for the system. Next we discard those which are not good candidate concepts for any one of a variety of reasons. In our case we discard:
- library, because it is outside the scope of our system
- short term loan, because a loan is really an event, which so far is not a useful object in this system
- member of the library, because it is redundant: it means the same as library member, which we keep
- week, because it is a measure of time, not a thing
- item, because it is vague: when we clarify it we see that it means book or journal
- time, because it is outside the scope of the system
- system, because it is a part of the language of requirements description, not a part of the domain
- rule, for the same reason
This leaves:
- book
- journal
- copy (of book)
- library member
- member of staff
Notice that library members and members of staff are people who use the system. In our case, the corresponding objects will represent them and will capture all the information about their "owners".
Relations Between Concepts
Next we identify and name relationships or associations between our concepts. We do this for two reasons:- To clarify our understanding of the domain, by describing our objects in terms of how they work together;
- To sanity-check the coupling in our system, i.e., make sure that we are following good principles in modularizing our design.
To help us identify associations we can use some known patterns: A is physically a part of B, A is a logical part of B, A is physically contained in B, A is logically contained in B, A is a member of B, A uses or manages B, A communicated with B, A is an organizational subunit of B, and more. In this case we can see that:
- a copy is a copy of a book
- a library member borrows/returns a copy
- a member of staff borrows/returns a copy
- a member of staff borrows/returns a journal
We can record this information pictorially as follows:
MemberOfStaff shares in all the same associations that LibraryMember does, and that this agrees with our intuition that a member of staff is a kind of library member. Recording this in the static diagram will clarify our understanding of the situation, that there is a generalization relationship between LibraryMember and MemberOfStaff. Note that we may or may not choose to implement this generalization relationship using inheritance - that design decision will depend on deeper understanding of the system (and will be carefully discussed later in the course).
The system in action
So far we have sketched the static structure of the system, but we have not yet described its dynamic behavior: for example, we have yet to record how the objects in the system work together to allow a user to borrow a copy of a book. In UML we can use interaction diagrams to show how messages pass between objects of the system to carry out some task - for example, to realize a particular use case. The following diagram shows the interaction diagram for the borrowing of a copy of a book by a library member.