Johns Hopkins University Software Engineering Fall 2002

1
Johns Hopkins UniversitySoftware
EngineeringFall 2002

• 8 October 2002
• Bill Akin

2
Tonights Agenda

• Documentation and Microsoft Word

3
Schedule

• Class Date Chapters Events and Deliveries
• 1 10-Sep Overview
• 2 17-Sep Project and team organization
• 3 24-Sep 1, 2, 3, 4 Present team project
  proposals
• 4 1-Oct 5, 10, 11
• 5 8- Oct 12, 13, 14, 15 Deliver proposal
  document
• 6 15-Oct 16, 20, 21 Present requirements
  analysis
• 7 22-Oct Mid-Term Exam
• 8 29-Oct 22 Present analysis models
• 9 5-Nov Deliver requirements document
• 10 12-Nov 6, 7, 8, 9, 19, 24 High Level Design
  Presentation
• 11 19-Nov 17, 18, 23 Deliver high level design
  document
• 12 26-Nov Part Five Topics
• 13 3-Dec Project Demonstrations - Deliver
  project
• 14 10-Dec Final Exam

4
Front Matter

• Cover Page
• Title of your paper
• Date
• Your Names
• Name of the Class
• Abstract
• A brief description of what the paper is about
• An abstract for these papers might be around 1/3
  page
• Tables
• Table of Contents
• Table of Figures
• List of Tables (Tables in the main body)

5
Main Body

• Introduction Section
• Summary -- 1-3 paragraphs that tell the reader in
  brief what the rest of the document says
• Purpose -- Tells reason for research and paper
• Approach -- Tells how you developed the
  information in the paper
• Scope -- How much of the topic will be covered
• Background -- Optional material that helps the
  reader see the context of your subject

6
Main Body

• Supporting Sections
• Develop the major subjects that lead to your main
  theme
• Usually not more than 4 or 5 subjects. None
  longer than the main
• Main Theme
• Make your point
• Support your point by relating to your major
  supporting sections

7
Appendices

• Convenient references for your audience
• Examples include
• Acronyms
• Definitions of terms
• References
• Supporting material
• Each appendix is a separate section

8
General Rules and Guidelines

• Acronyms -- The first time an acronym is used it
  should be spelled out followed by the acronym in
  parenthesis, for example International Standards
  Organization (OSI). Every time after that it can
  just be the acronym, for example OSI.
• Tables and Figures -- If tables or figures appear
  in the text, they must be referenced in the text.
  Table titles go above tables. Figure captions
  go below figures.

9
System Modeling

• Create a model of system capabilities (Were
  still in the problem space.)
• Model should represent
• Input,
• Processing,
• Output,
• User interface, and
• Maintenance.

10
System Modeling

• Modeling should be recursive and hierarchical.
• For most models the top level view is called the
  context view.
• The context view depicts the system in the
  context of its environment, including external
  entities that directly interface and interact
  with the system.

11
System Model Template

• The model in Figure 10.5 can be viewed as a
  schematic for models.
• Models take different forms but generally address
  the same basic features.
• Most classic models do not separate the user
  interface and maintenance views. These can be
  viewed as input, output, and/or process functions.

12
System Context Diagram

• The context diagram in Figure 10.6 depicts a
  particular instance.
• It shows the system needed in the processing
  pane, the barcode reader and conveyor line in the
  input pane the sorting station operator in the
  user interface pane, the sorting mechanism and
  mainframe in the output pane, and repeats the
  sorting station operator in the maintenance pane.

13
Problem Space Models

• The models capture the view of the functions to
  be performed by the system.
• It is more likely that solution space groupings
  lie along common computer functions than along
  common user functions.
• For example, user interface activities or data
  management functions may be grouped.

14
Requirements Engineering

• Requirements engineering can be described in
  distinct steps
• Requirements elicitation,
• Requirements analysis and negotiation,
• Requirements specification,
• System modeling (in the problem space),
• Requirements validation, and
• Requirements management.

15
Requirements Elicitation

• Learn from the stakeholders about the problem the
  system is to solve.
• Listen carefully and capture every idea from each
  person who will share his or her vision.
• Record everything even though some inputs may
  conflict with others.
• Get only enough to help you understand what is
  required. Youll be back for details and
  clarification later.

16
Elicitation Steps

• Assess feasibility
• Identify contributors
• Define environment
• Identify domain constraints
• Define elicitation methods
• Solicit participation
• Identify requirements prototyping candidates
• Create usage scenarios

17
Elicitation Products

• Statement of need and feasibility
• Bounded statement of system scope
• List of customers, users, and other stakeholders
• Description of systems technical environment
• List of requirements and domain constraints
• Set of usage scenarios
• Any prototypes developed

18
Requirements Analysis and Negotiation

• Systems engineers take possession of emerging and
  evolving artifacts.
• The systems engineering process becomes the
  customer of the requirements engineering process.
• Systems analysts still perform refinement of the
  products they have delivered.
• Systems analysts deliver a validated, living
  requirements specification.

19
Software Requirements Analysis

• Software requirements analysis bridges the gap
  between system requirements engineering and
  software design.
• Software requirements analysis is divided into
• Problem recognition,
• Evaluation and synthesis,
• Modeling,
• Specification, and
• Review

20
Analysts Must Determine

• Are requirements consistent with objectives?
• Are specifications at the appropriate level?
• Is each requirement necessary or enhancement?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution?
• Are there conflicts between any requirements?
• Is each requirement achievable in environment?
• Is each requirement testable, once implemented?

21
Requirements Specification

• A requirements specification defines a view of
  the problem space. It does not always define a
  particular system to be built.
• A given system, version of a system, or release
  of a version of a system should satisfy a subset
  of the problem space defined by the requirements
  specification.
• The subset that specifies a certain system is
  called a requirements baseline.

22
Requirements Validation

• In addition to the ultimate system user, others
  have a stake in the requirements specification.
• All stakeholders should validate the requirements
  specification to be sure the requirements are
  unambiguous, consistent, complete, correct, and
  compliant.
• Important stakeholders include testers,
  developers, managers, etc.

23
Requirements Management

• Every version of the requirements specification
  must be submitted to software configuration
  management (SCM) -- often just called CM.
• Additions, changes, and deletions to requirements
  must be done through a controlled process and
  submitted to CM.
• Requirements baselines must be identified.

24
Object-Oriented Concepts and Principles

• Pressman For many years, the term object
  oriented (OO) was used to denote a software
  development approach that used one of a number of
  object-oriented programming languages (e.g.,
  Ada95, C, Eiffel, Smalltalk).
• If we want to do object-oriented development,
  what the heck is an object?

25
Whats an Object?

• An object is sometimes defined as an instance of
  a class.
• An object is also called an instantiation of an
  abstract data type.
• These definitions of an object fail to define an
  object we might use in object-oriented design or
  object-oriented requirements analysis.

26
Objects

• Definition An object is an entity which has a
  state and a defined set of operations to access
  and modify that state. Som89
• Constructor operations modify an objects state.
• Access operations access the objects state.
• We can also think of an object as a closed
  system, subsystem, or component that maintains
  its own state, accepts a specified set of
  messages, provides responses, and/or performs
  pre-defined functions.

27
Attributes of OO Approaches

• Examples of objects include a juke box, an ATM,
  a robot, a software module, etc.
• Classes objects are generally instances of
  classes. Object-A is a Class-G. Roger is a
  robot. Billing-Address is an Address-Class.
• Inheritance Class-Red-Dogs is a Class-Dog that
  also has an attribute that it is Red. This is
  not a new concept. We have other
  classifications. Monkeys are Primates with long
  tails. Primates are man-like Mammals.

28
Attributes of OO Approaches

• Encapsulation data and procedures are
  encapsulated in the class definition.
• Part of the class definition is its attributes.
• Part of the class definition is its methods.
• PARTY Birthday.George (Today) is a statement
  that returns a TRUE value to PARTY if today is
  Georges birthday.
• If PARTY then SING

29
Attributes of OO Approaches

• George is an instance of the class Person.
• Today is a date value for todays date.
• PARTY is a Boolean variable.
• Birthday is a method defined on the class Person
  that returns a Boolean value.
• From what we can see, we dont know how the
  attributes of Person are held. In a good design
  we should never know.

30
Inheritance

• An instance of a class can be a subclass or an
  object.
• Red car is a subclass that is an instance of the
  class car
• Joes car is an object that is an instance of the
  class car
• Joes car has all the attributes of the class
  car.
• All red cars have the same attributes plus those
  attributes that extend to the class red car.

31
Methods

• Constructor Changes state
• Joes_Car.Set_Color (Red)
• My_Checking.Withdraw (75.68)
• Access Retrieve state information
• Print Joes_Car.Make
• Print My_Checking.Balance
• Print Point_A.Distance (Point_B)
• Note that Balance may be calculated from state
  data of the object My_Checking and Distance is
  computed relative to an input parameter.

32
Objects and Classes
Car
Point
My_Checking
Latitude Longitude
Set_Color Make Age
Withdraw Balance Deposit
Distance Name Set_Lat Set_Long
33
Entities and Objects

• At entity, in an information system, is a
  representation of a thing from the real world.
• An example is a person in a Microsoft Outlook
  contact list. The entry for Bill Akin is an
  entity.
• An object is more than an entity. It is the
  information and the encapsulated operations on
  the entity.
• An entity has attributes. An object has
  attributes and methods.

34
Objects

• Definition An object is an entity which has a
  state and a defined set of operations to access
  and modify that state. Som89
• Constructor operations modify an objects state.
• Access operations access the objects state.
• We can also think of an object as a closed
  system, subsystem, or component that maintains
  its own state, accepts a specified set of
  messages, provides responses, and/or performs
  pre-defined functions.

35
Object Oriented Approaches

• We are considering three object oriented
  approaches in software engineering
• OO Architecture
• OO Analysis
• OO Design
• OO Programming
• There are many other OO approaches.

36
Attributes of OO Approaches

• Classes objects are generally instances of
  classes.
• Encapsulation data and procedures are
  encapsulated in the class definition.
• Inheritance An object inherits the attributes,
  operations, and methods of its class. New
  classes can inherit all features of their parent
  classes.

37
Methods

• Constructor Changes state
• Joes_Car.Set_Color (Red)
• My_Checking.Withdraw (75.68)
• Access Retrieve state information
• Print Joes_Car.Make
• Print My_Checking.Balance
• Print Point_A.Distance (Point_B)
• Note that Balance may be calculated from state
  data of the object My_Checking and Distance is
  computed relative to an input parameter.

38
OO Architecture
Data
User
User
Data
Data
Data

• Subsystems can be viewed as objects.
• Each hides its state and is accessed by methods.
• There is some infrastructure to support this.

39
Next Week

• Use-Cases
• Analysis Models
• Architecture Models