Ivan Marsic • Rutgers
University 56
Another place to look is: University of Florida’s Gator Tech Smart House [Helal et al., 2005], online at: http:www.harris.cise.ufl.edugt.htm
For the reader who would like to know more about home access control, a comprehensive, 1400- pages two-volume set [Tobias, 2000] discusses all aspects of locks, protective devices, and the
methods used to overcome them. For those who like to tinker with electronic gadgets, a great companion is [O’Sullivan T. Igoe, 2004].
There are many excellent andor curious websites related to software engineering, such as: Teaching Software Engineering – Lessons from MIT, by Hal Abelson and Philip Greenspun:
http:philip.greenspun.comteachingteaching-software-engineering
Software Architecture – by Dewayne E. Perry:
http:www.ece.utexas.edu~perryworkswa
Software Engineering Academic Genealogy – by Tao Xie:
http:www.csc.ncsu.edufacultyxiesefamily.htm
D. Coppit, “Implementing large projects in software engineering courses,” Computer Science Education, vol. 16, no. 1, pp. 53-73, March 2006. Publisher: Routledge, part of the Taylor
Francis Group
J. S. Prichard, L. A. Bizo, and R. J. Stratford, “The educational impact of team-skills training: Preparing students to work in groups,” British Journal of Educational Psychology, vol. 76, no. 1,
pp. 119-140, March 2006.
downloaded: NIHRandallMATERIALS2 M. Murray and B. Lonne, “An innovative use of the web to build graduate team skills,” Teaching
in Higher Education, vol. 11, no. 1, pp. 63-77, January 2006. Publisher: Routledge, part of the Taylor Francis Group
57
Contents
2.1 Software Development Methods
2.1.1 2.1.2
2.1.3 Agile Development 2.1.4
2.2 Requirements Analysis and Use Cases
2.2.1 Types of Requirements 2.2.2 Use Cases
2.2.3 Requirements Elicitation through Use Cases
2.2.4 Modeling System Workflows 2.2.5 Risk Analysis
2.3 Analysis: Building the Domain Model
2.3.1 Identifying Concepts 2.3.2 Concept Associations and Attributes
2.3.3 Contracts: Preconditions and Postconditions
2.4 Design: Assigning Responsibilities
2.4.1 Design Principles for Assigning Responsibilities
2.4.2 Class Diagram 2.4.3
2.4.4 Why Software Engineering Is Difficult 2
2.5 Software Architecture 2.6 Implementation
2.6.1 2.6.2
2.7 Summary and Bibliographical Notes Problems
Chapter 2
Object-Oriented Software Engineering
The first issue to face with large-scale product development is the logistics of the development and the management issues.
Software product development has some peculiarities not present in other engineering disciplines, mainly because
software is abstract as well as more complex and more flexible than any other artifact. These peculiarities will be seen to
influence the logistics and management of software development. In the following presentation, I will
deemphasize development methodology or structured process of development for the reasons explained below. My main
goal is to explain the concepts and describe the tools for software development. These concepts and tools are
applicable over many different methodologies. Having learned the concepts and tools, the reader can pick their favorite
methodology.
The presentation is organized to present the material in a progressively increasing depth. Already, Section 1.2 briefly
overviewed the stages of the software engineering lifecycle. Now, each stage is detailed in this chapter. System
specification is further elaborated in Chapter 3 and software design is elaborated in Chapter 5.
2.1 Software Development Methods
The goal of software methodologists is to understand how expert developers work and convey this to students. Plus, the hope is that new insights will emerge about how to effectively do
product development, so even experts might benefit from learning any applying methodology. The truth is, life cycle methods are rarely followed in real life of people’s own will; those who do
Ivan Marsic • Rutgers
University 58
are usually forced to follow a certain methodology due to the company’s policy in place. Why is it so, if following a method should be a recipe for successful projects?
There are several reasons why methodologies are ignored or meet resistance in practice. One reason is that methodology is usually derived from a past experience. But, what worked for me
may not work for you. Both developers and projects have different characteristics and it is difficult to generalize across either or both categories. A “one-size-fits-all” approach simply
cannot adequately describe complex human activities, such as software development. In addition, method development takes relatively long time to recognize and extract “best practices.” By the
time a method is mature, the technologies it is based on may become outdated. The method may simply be inappropriate for the new and emerging technologies for example, Web Services,
described in Chapter 8.
A development method usually lays out a prescriptive process by mandating a sequence of development tasks. Some methods devise very elaborate processes in which a rigid,
documentation-heavy methodology is followed with very detailed specifications. The idea is that the developers should follow each step exactly as predetermined and a successful project will be
result. In other words, if the rules are followed, it does not matter who carries them out— regardless of the developer’s knowledge and expertise, a mere method adherence leads to a
success. Even if key people leave the project or organization, the project should go on as scheduled because everything is properly documented. However, we experience teaches us that
this is not the case. Regardless of how well the system is documented, if key people leave, the project suffers.
Recent methods, known as agility, attempt to deemphasize process-driven documentation and detailed specifications. They also take into consideration the number and experience of the people
on the development team.
The hope with metaphors and analogies is that they will evoke understanding much faster and allow “cheap” broadening it, based on the existing knowledge.
2.1.1 Agile Development
Agility is both a development philosophy and a collection of concepts embedded into development methodologies. An agile approach to development is essentially a results-focused
method that iteratively manages changes and risks. It also actively involves customers, making them in effect a part of the development team. Unlike process-driven documentation, it promotes
outcome-driven documentation.
Agile development evangelists tell us that the development should be iterative, with quick turnover, and light on documentation. They are believers in perfection being the enemy of
innovation. This is all well and fine, but it does not tell us anything about where to start and how to proceed. Selecting a line of attack is a major obstacle, particularly for an inexperienced
developer.
One problem is with this is that when thinking about a development plan, an engineer usually thinks in terms of methodology: what to do first, what next, etc. Naturally, first comes discovery
studying the problem domain and finding out how the problem is solved now and proposing how
Chapter 2 • Object-Oriented Software Engineering
59
it can be solved better with the to-be-developed technology; then comes development designing and implementing the system; lastly, the system is deployed and evaluated. This sequential
thinking naturally leads to the waterfall model and heavy documentation.
The customer does not see it that way. The customer would rather see some rudimentary functionality soon, and then refinement and extension.
AGILE VS. SLOPPY
♦
I have had students complain that demanding readability, consistency, and completeness in project reports runs against the spirit of agile development. Some software engineering
textbooks insist on showing snapshots of hand drawn UML diagrams, as opposed to neat diagrams created electronically, to emphasize the evanescent nature of designs and the need for
dynamic and untidy artifacts. This may work for closely knit teams of professionals, working in adjacent offices exclusively on their project. But, I found it not to be conducive for the
purpose of grading student reports: it is very difficult to discern sloppiness from agility and assign grades fairly. Communication, after all, is the key ingredient of teamwork, and
communication is not improved if readability, consistency, and completeness of project reports are compromised. I take it that agility means: reduce the amount of documentation but not at
the expense of the communicative value of project artifacts. Brevity is a virtue, but we also know that redundancy is the most effective way to protect the message from noise effects.
2.2 Requirements Analysis and Use Cases
Requirements analysis starts with the problem definition: customer statement of requirements. The problem could be identified by management personnel, through market research, by
ingenious observation, or some other means. Defining the requirements for the planned system includes both fact-finding about how is the problem solved in the current practice as well as
envisioning how the planned system might work.
2.2.1 Types of Requirements
System requirements make explicit the characteristics of the system that is to be developed. Requirements are usually divided into functional and non-functional. Functional requirements
determine how the system is expected to behave and what kind of effects it should produce in the application domain.
Non-functional requirements describe system properties that do not relate to the system function. An example of a non-functional requirement is: Maintain a persistent data backup, for the cases
of power outages.
FURPS+ Non-functional also known as “emergent” system properties:
