The document discusses the essential steps of system analysis and design, focusing on the transition from design to implementation. It covers considerations for choosing programming languages, architectural decisions, and the importance of understanding UML in mapping designs to code. Additionally, it highlights the incremental development approach and the roles of abstract classes and interfaces in software design.

1. +
Nuts and Bolts (1)
Systems Analysis and Design
Michael Heron

2. +
Introduction
 For now, we have reached the end of our discussion on how to
analyse and design a system.
 The next stage is talking about what happens next – the nuts and
bolts of putting a system together.
 Analysis and Design is implementation agnostic.
 It presupposes a ‘class’ of implementation languages, but not
specifics.
 SSADM will imply a standard procedural language.
 UML will imply an object oriented language.
 Turning a design into an implementation is an important and
complex task for developers.
 The design says how, but the developers must carry that out.

3. +
Development from a Design
 In its ideal form, a design document can be transcribed into an
implementation language without much difficulty.
 If the design is at the correct level of abstraction to be implemented.
 More often though, developers must interpret design
documents in a way that is harmonious with the overall
architecture of a system.
 They don’t change infrastructure, but they may choose specific
implementations.
 Rarely will a design be possible to implement one for one.
 And there is much scope for a developer here to creatively tweak a
model.

4. +
Mapping from UML
 Each of the documents produced in UML gives a view of a
specific part of the eventual system.
 Class diagrams lead to class structures.
 Activity diagrams lead to method implementation
 Use cases lead to user interface choices
 Sequence diagrams show the order of invocation of methods
 This doesn’t cover the entirety of what needs to be coded.
 We have left out a number of diagrams from the module.
 However, it should be possible in many respects to directly
translate these into code.

5. +
A Class Diagram
Book
- name: String
- ISBN : String
- Author: String
+ getName() : String
+ setName(n : String)
+ getISBN() : String
+ setISBN(i : String)
+ getAuthor(): String
+ setAuthor (a : String)
Library
- books[] : Book
+ addBook (b : Book)
+ removeBook (b : Book)
+ findBook (t: String) : Book
+ listBooks () : Book[]

6. +
To The Code
 Everything we need to build the structure of a program is
contained in here.
 We just need to decide on an implementation language.
 Our first decision here is important, it will greatly influence what
happens next.
 A good understanding of languages and their benefits/drawbacks
lets you make an informed choice.
 There is no real difference in ‘difficulty’ between languages in a
particular classification.
 They all have strengths and weaknesses though.

7. +
Language Considerations
 ‘You go to war with the army you have’
 This means that competency within a team is an important
consideration.
 There’s no point picking Java as an implementation language if nobody
knows it and there isn’t time to learn.
 Your first consideration will derive from the design you have put in
place.
 Do you require multiple inheritance?
 If so, your choices are limited.
 Can any multiple inheritance in the system be resolved through the use
of interfaces?
 In most cases this is true.
 Can the model be adjusted to resolve remaining shared code problems.
 Possible through some design patterns.

8. +
Language Considerations
 If you don’t require multiple inheritance, things become much
easier.
 You have more options as to what you can choose.
 You then need to consider what the key elements of the system
are going to be.
 Is it high traffic?
 Is it heavily GUI based?
 Does it have to run over multiple systems?
 Does it need to be web enabled?
 Does it involve databases?
 Does it need to be ported to multiple systems?

9. +
Language Considerations - Java
 Java is for many developers their ‘default’ language.
 It has a good blend of everything without any serious flaws.
 Java runs on a ‘virtual machine’ which allows for it to be decoupled from
the underlying hardware.
 This makes it very easy to port from one environment to another.
 Java allows for an easy conversion between desktop applications and web
applets.
 Although the latter have some security limitations.
 Java however is resource heavy.
 While it is not noticeably slower than other languages when a program is running,
it takes longer and more memory to get it running.
 It’s a well supported language with a vibrant developer base.
 There’s lots of frameworks and such out there you can use.

10. +
Language Considerations – C++
 C++ is one of the precursors to Java.
 Pointer driver object orientation.
 It supports multiple inheritance.
 Although this is as much a curse as a blessing.
 Performance wise it has the potential to be very good.
 But any tool is only as good as the person using it.
 Very easy to mis-use and mis-implement.
 C++ code is significantly more complicated than other OO languages
because of the issues of pointers.
 Tied to its implementation.
 Porting is an extra task.

11. +
Language Considerations - .NET
 For the .NET architecture, the specific language you choose is
syntactic only.
 They all compile down to exactly the same bytecode.
 Much like a ‘multi language’ version of Java.
 However, while there are open source implementations of the
.NET runtime, they suffer from problems.
 Not feature complete
 Don’t keep pace with Microsoft releases.
 .NET is best considered a windows technology.
 Porting to other platforms is fraught with difficulties.
 However, the .NET platform has considerable traction.
 Most developers will be familiar with some flavour of it.

12. +
Once you’ve chosen
 Once you’ve chosen a language, the next thing to do is put the
architecture of your classes in place.
 Make abundant use of placeholders here.
 You want to get all the classes into the program, in a form that
allows your system to compile.
 This will involve putting in method stubs for each of your
behaviours.
 It will also involve implementing the specific links between classes
implied by attributes.
 This is an important first step.
 It ensures everything links up properly.

13. +
Implementation
 Here, the language we choose starts to be important.
 UML represents getters/setters as separate methods.
 As is done in C++ and Java.
 .NET however has a specific syntactic form for these.
 They’re done as properties.
 This allows for a number of benefits regarding reflection of
classes and member attributes.
 If we choose to implement in a .NET language, we have to
choose the best form of implementation for what’s in our
design.

14. +
Implementation
 UML usually does not imply a particular kind of data structure
for implementation.
 Other than what is shown in associations and aggregations.
 Whenever we see the ‘array’ symbol in a design, we have the
specific choices as to how it should best be implemented
 Do we want a standard fixed size array?
 An ArrayList which will expand as we add elements to it?
 A linked list?
 A hashtable?
 We need to view a class in terms of the kind of interactions we
will need to perform with the data.

15. +
Implementation
 If we are going to be doing a lot of iterating over data, then an
array or similar collection might be useful.
 If we are going to be working primarily with individual data
elements, a hashtable (or dictionary, or mapping, or however you
know it) might be better.
 This will have implications for how the rest of the system works,
and choosing the right data structure will make everything easier
to do.
 You should decide upon this as you implement the architecture.
 You’re not stuck with it, and good OO discipline will ensure a limited
impact of change if you decide to change your mind.

16. +
Implementation - Java
public class Book {
private String name;
private String ISBN;
private String Author;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getISBN() {
return ISBN;
}
public void setISBN(String ISBN) {
this.ISBN = ISBN;
}
public String getAuthor() {
return Author;
}
public void setAuthor(String Author) {
this.Author = Author;
}
}

17. +
Implementation - Java
import java.util.*;
public class Library {
ArrayList<Book> books;
public Library() {
books = new ArrayList<Book>();
}
void addBook (Book b) {
books.add (b);
}
void removeBook (Book b) {
books.remove (b);
}
Book findBook (String b) {
return null;
}
ArrayList<Book> listBooks() {
return books;
}
}

18. +
Implementation – VB .NET
Public Class Book
Private myName As String
Private myISBN As String
Private myAuthor As String
Property Name() As String
Get
Return myName
End Get
Set(value As String)
myName = value
End Set
End Property
Property ISBN() As String
Get
Return myISBN
End Get
Set(value As String)
myISBN = value
End Set
End Property
Property Author() As String
Get
Return myAuthor
End Get
Set(value As String)
myAuthor = value
End Set
End Property
End Class

19. +
Implementation – VB .NET
Public Class Library
Dim books As ArrayList
Public Sub New()
books = New ArrayList
End Sub
Public Sub addBook(b As Book)
books.Add(b)
End Sub
Public Sub removeBook(b As Book)
books.Remove(b)
End Sub
Public Function findBook(n As String) As Book
Return Nothing
End Function
Public Function listBooks() As ArrayList
Return books
End Function
End Class

20. +
Implementation
 Note that there is very little functionality here.
 Only that which is required to make the system compile.
 We approach this from a principle of incremental development.
 The findBook method for example is a placeholder.
 Our activity diagrams/pseudocode will take us from the
placeholder to the proper implementation.
 As part of a ‘proper’ design model, there will be diagrams and
pseudocode to represent all of these functions.
 Where they touch on other parts of the system, they will be shown in
sequence diagrams.

21. +
Implementation
 We’ll look at those parts of the system next week.
 We still have to discuss some things about the class design.
 Ideally, most of the architectural issues are handled at design time.
 However, the language chosen will allow for certain elegancies to
be introduced.
 C++ has no concept of an interface for example.
 Certain classes in a system will be expected to be abstract.
 Never instantiated.
 Our first implementations of the class diagram should honour both
of these conventions.

22. +
Abstract and Interface
 An abstract class is one which serves as a polymorphic base for
other classes, but is never intended to be instantiated itself.
 It doesn’t have enough context about it.
 A good class diagram will identify when classes are expected to be
abstract.
 This is indicated in UML by putting the class name in italics.
 A good class diagram will identify when polymorphic structure is
needed without code.
 These are interfaces.
 These are indicated with the class name in <<Angle Brackets>>
 And the implementation of these interfaces is represented by a
dashed line.

23. +
Abstract and Interface
 Strictly speaking, abstract classes are not necessary.
 You can just choose not to instantiate particular classes.
 However, the use of an abstract class requires that any child class
provide implementations of abstract methods.
 Or that they themselves are declared as abstract.
 This should be represented in a class diagram, but part of building
the class structure is to ensure the classes are properly designed.
 It should compile once you have implemented the bare bones of
everything.
 The first stages of implementation will help inform design as part
of the regular ‘give and take’

24. +
Abstract and Interface
 An interface is slightly different – it’s the mechanism many single
inheritance languages use to give multiple polymorphic ‘contracts’.
 Interfaces come with no code, but they do come with a set of
methods.
 A ‘contract’ that must be met before your system will compile.
 Interfaces allow for polymorphism to be more flexible than strict
inheritance permits.
 And as such, should be used where possible to make a system easier
to work with.
 Ensuring that your system compiles will show that interface
contracts are met.

25. +
Conclusion
 This is the first part of our implementation – creating the initial
class representations.
 This takes us a surprising way towards the eventual implemented
system.
 Next week we’ll look at implementation of features and
incremental development of functions.
 Moving towards having an actual working program.
 The week after we’ll look at how the use-case diagrams inform
our development of the user interface.
 Although we shouldn’t leave that to the last minute for all kinds of
reasons.