Post on 18-Dec-2015
Software Development2D1385
2007
Karl Meinke
CSC
KTH
karlm@nada.kth.se
1.1. Goals of the Course
• After the course you should be able to:
1. Perform an object-oriented analysis of an informal text-based software requirements document, identifying ambiguities, omissions and inconsistencies; translate such a document into object-oriented requirements using a Noun/Verb/Relational-Phrase methodology, and construct a data dictionary.
2. You should be able to translate the information contained in a data dictionary into a UML class diagram which accurately models the same information, including aggregation, inheritance and multiplicity .
3. You should be able to draw a UML object diagram which correctly instantiates a class diagram under different data constraints. You should be able to abstract information from one or more object diagrams to derive a class diagram.
4. You should be able to critically analyse a short description of a software engineering project and an IT company's business model, and based on this analysis you should be able to recommend a software lifecycle model that is appropriate to the company and the project .
5. You should be able to critically analyse a short description of a software engineering project, and based on this analysis you should be able to recommend a global software architecture and small scale software patterns that are appropriate to the project.
6. You should be able to design and understand language independent data models, based on XML, that can be used to define data interchange standards between software systems, databases, files and communication protocols. You should understand the relationship between data models based on UML class diagrams and DTD data models, so that you can convert between the two. This understanding must also extend to UML object diagrams and XML data files, so that again you can convert between the two.
7.You should understand and be able to use a variety of advanced Java programming features, including Swing GUI components, exceptions, network programming and concurrency, and be able to apply these to small practical exercises arising from lab work.
User Requirements
Software Requirements
Architecture Design
Detailed design & coding
Testing
Delivery
Course Objectives on a Waterfall Model Project
Time
UML + OO requirements analysis
Architectures +Patterns + OO design + XML
Java exceptions +sockets + threads
JUnit
1.1. Övningar
• Designed to help you pass the exam
• Include exercises and past exam papers
• Myself (classes in english)
• Lars Arvestad (classes in swedish)
1.2. Lab Exercises
• Labs 1,2 Java API, Graphics, event handling
• Lab 3 client-server with sockets
• Lab 4 XML, syntax and parsing
• Lab 5 build a web browser using Java Swing components
• Extra lab 6 (see list) bonus points
1.3. Course Book
“Software Design” by Eric Braude, 2004Chapters: 0-2 Programming Concepts3: Unified Modeling Language UML4-5: Software Design Principles6-9: Design Patterns10-12: Software Components (Beans .NET)13-14: Software architecture
1.5. Checklist for Submitting Lab Work
• Show your UML –design (lab 2-6)
• Which architectures/design patterns have been used? (labs 3-6)
• Which engineering/management model has been used? (lab 4-6)
• How have you documented your program (comments, javadoc etc.) (labs 5-6)
1.5. Checklist (2)
• How have you achieved abstraction, encapsulation and modularity?
• Which classes have you reused from earlier labs? (With refactoring?)
• Which new classes have you used, and why?
• Explain how robustness, and reusability are satisfied
1.5. Checklist (3)• How have you performed functional testing?• Point out the most critical pieces of code.• In retrospect, what would you have done
differently if the project had continued?• Demonstrate using a program execution that the
functional and design requirements are satisfied• Keep it brief !!!!!!!!!!!!!!!!
2.0. Requirements Capture and Analysis with UML
The Unified Modeling Language (version 2.0)
• Class/Object diagrams (static)
• Sequence diagrams (dynamic)
• Activity diagrams (dynamic)
• Statecharts (dynamic)
Standard developed by OMG adopting earlier
ideas (Booch, Rumbaugh, Jacobson)
2.1. Requirements Models
Models express requirements, architecture &
detailed design. (Video Game examples)
Use Case Model: In this situation do the following …
e.g. how to engage a foreign character
Object / Class Model: with objects of these classes …
Object provides a set of services, e.g. engagement class.
State Model: by reacting to these events …
state/event reaction
e.g. if foreign character shoots while we are friendly … run away
2.2. O-O Analysis & Design with UML 2.0
The basic OOA&D approach (iterative)
1. State the main use cases
2. Convert the use cases to sequence diagrams
3. Select the resulting domain classes
4. If not finished goto 1.
2.3. UML Use Case DiagramsUML gives us a graphical language toorganize all our use case scenarios into one overview:
Use Case DiagramsThese display organisation of:• actors• use cases• associations, • dependencies
Activate
Check in
Check out
Add video
Clerk
Stocker
Precondition: app has been activated
1. Clerk clicks “check out”
2. Clerk swipes bar code
3. …
Postcondition: video is registered to customer
UML Comment
requires
Add customer
requiresincludes
UML Dependency
11
1
*
Clerk
1 – one and only one
Actor with role name, use case dependencyand multiplicity
Activate
Use case with name and dependent actors and multiplicities
*
* - zero or more
1 … * - one or more
Precondition: app has been activated
1. Clerk clicks “check out”
2. Clerk swipes bar code
3. …
Postcondition: video is registered to customer
Pre and postconditiondescribing black-box effect of executing a use case onthe system
Expressed as a comment only
requires
A
B
Use case dependency
A requires B - B must complete before A startsA equivalent B – identical activities and flow, but user
sees them as differentA extends B – all activities of B are performed but A
adds activities or slightly modifies them. Can use to refactor or simplify use cases
2.4. Use Case ModelingIn O-O based IT projects, we can begin the
requirements analysis phase with a
Use Case Analysis
A use case is a common or representative
situation where one or more external users
and/or systems interact with the system to
solve an instance of a common problem
Notice the underlined word “common”
Software seems to obey the statistical Pareto Law
90% of time is spent executing just 10% of the code
Therefore care in designing just this 10% of code is “cheap” and will give a good product 90% of the time (at least in theory!)
Note: we want to decouple
specific users (e.g. John Smith)
From their roles, e.g.
student, teacher, systems administrator, etc.
A role will be called an actor.
A specific proper noun (object)
e.g. Karl Meinke, may play several roles:
teacher, researcher, sys_admin ... etc.
Use case modeling involves three steps
that are repeated until we are satisfied.
Step 1. Identify, name and define each actor
in terms of:
(a) Goals, i.e. what the actor wants to do,
(b) Needs, i.e. what services from the system
the actor requires to meet each goal.
Step 2. For each system service
(identified in Step 1), informally describe the
• preconditions and
• results of the service, and its,
• interaction with the actors in: – a typical case (sunny day scenario). – exceptional and error cases (rainy day scenario)
Such a service description is called an informal description of a use case scenario.
Step 3. For each informal description which
is:
– mission critical
– unclear, or
– ambiguous
formalise the interaction of the system and
the relevant actors using a sequence diagram
Step 4. [If necessary, repeat Steps 1-3]
Makes an iterative requirements analysis
1. Actors
2. Use cases
3. SequenceDiagrams
2.5. Example
Let us analyze requirements on a
Warehouse management system
Step 1. We begin by identifying nouns, verbs
and relational phrases in a requirements
document.
Warehouse Management SystemRequirements Document
The system will support warehouse management.
A warehouse worker loads goods from a truck and logs in
and out goods using a database. The goods are delivered by a
truck driver between warehouses, and distributed within a
warehouse by a forklift truck driver. Each warehouse is
managed by a foreman, who is able to move goods between
warehouses with or without a customer order. A foreman is
also able to check the status of a customer order.
The requirements document can be
marked up as follows.
Warehouse Management SystemMarkup Document
The system will support warehouse management.
A warehouse worker loads goods from a truck and logs in
and out goods using a database. The goods are delivered by a
truck driver between warehouses, and distributed within a
warehouse by a forklift truck driver. Each warehouse is
managed by a foreman, who is able to move goods between
warehouses with or without a customer order. A foreman is
also able to check the status of a customer order.
The marked up document information can be
represented in a data dictionary as follows:
NounsForeman: actor, responsible for one warehouse.
Warehouse Worker: actor, works in a warehouse loading and unloading goods.
Good: an item to be stored in a warehouse
Warehouse: a place to store many goods
VerbsLoad: A warehouse worker loads goods onto a truck and
logs out goods from warehouse using a database.
Relational PhrasesForeman responsible for warehouse: One foreman is
responsible for one warehouse.Table 2.5.1
Notice how we marked up:
• Nouns: e.g. foreman, warehouse, …
• Verbs: e.g. loading, unloading …
• Relational Phrases: e.g. responsible for, works in, … (prepositions?)
(Notice the possible overlap between verbs
and relational phrases.)
This identification work is the heart of O-O
requirements analysis and design, since …
2.5.2. Central O-O Dogma
• Common Nouns e.g. warehouse, truck, correspond to classes and attributes
• Proper Nouns e.g. Karl, Fido, KTH, correspond to objects
• Verbs e.g. unload, correspond to methods
• Relational Phrases e.g. responsible for, correspond with system structure
We will study data dictionaries more in the exercise classes!!
The DD definitions are short, but enough to getStarted on Step 2. By iterating again later we can addmore details.
Step 2 asks to focus on the services which the system (warehouse management software) must provide.
We build a list of informal use case scenarios.
Not every noun will be an actor …
(does a forklift truck have any goals ???)
… but every actor will be a noun, so:
Actors Nouns
Step 2 requires us to look at each actor in turn
(in our case there are 4 actors) and ask:
• What does this actor want to do (all verbs)?
• What does the actor need from the system
to accomplish each activity (each verb)?
Let’s look at the 1st actor “foreman” and try
to identify the goals.
(a) A foreman has to be able to move items between warehouses with or without a customer order. This use case scenario is called “manual redistribution between warehouses”
(b) A foreman also wants to check how far a customer order has been processed. We call this use case scenario “check status of acustomer order”.
Let’s try to informally define the 1st use case
scenario: “manual redistribution between
warehouses”.
This could be broken down into 4 steps
(1) Initialisation: when a foreman gives a
request to do a redistribution.
(2) Planning: when the system plans how to
co-ordinate the various transports, and issues transport requests
(3) Loading: when a truck fetches the items
from a source warehouse.
(4) Unloading: when a truck delivers items
to a destination warehouse.
Is there anything wrong with this use case?
(1) It is very short!- but we can add detail later!
(2) It doesn’t say what happens if things go
wrong.
- We need to add exception/error cases.
- The more of these we add, the more
robust our system will be.
2.6. UML Sequence Diagrams
A use case scenario describes a
sequence of interactions
or
messages
between a
collection of actors and the system
in order to carry out some task
Often we would like to formally model
a use case scenario, to study:
• timing aspects (relative or absolute)
• communication patterns
• system states
• exception behavior
• alternative paths or behaviors
2.6.1. Elementary Concepts
A basic sequence diagram depicts a set of objects or
processes each of which has its own timeline.
Conventionally, objects go across the diagram
horizontally, while time goes down the diagram
vertically. Down the timelines, between
objects, we show messages.
C : Computer P : Print_server D : Device
>lprfile
print(file, device)print(file,size)
donedone
>done(time)
Here is our earlier sequence diagram drawn as an SD/MSC:
object/processtimeline message
time
SD Print
Notice that:• This basic SD has 3 objects and 6 messages• 1 message comes from the environment:
>lpr file (from the keyboard??)
• 1 message goes to the environment>done(time) (to the screen??)
• The environment is an implicit actor
• Each timeline has a terminating block at thebottom, which does not mean that the objectdissappears/ gets deleted, life goes on!!
2.6.2. The Time Concept
An SD/MSC must show
dynamic behavior over time
Down each timeline we see a set of events .
Each event may either be:
• sending of a message (arrow tail)
• receiving of a message (arrow head)
Each timeline shows the local relative orderbetween events, but not the absolute timeinterval between events.
Thus the basic model of time is relative (instead of absolute).
Also, for every message m:
send(m) occurs before receive(m)
This means that, e.g.
receive(>lpr file) occurs before
send( print(file, device) )
which occurs before
receive(done)
which occurs before
send(>done(time) )
and e.g. send(done)
occurs before receive(done)
We don’t know the absolute time between sending
and receiving a message, i.e. message delay.
e.g these two diagrams express the same scenario.
BA A B“a”
“b”
“a”
“b”
SD 1 SD 2