class: center, middle
Helge Pfeiffer, Assistant Professor,
Research Center for Government IT,
IT University of Copenhagen, Denmark
[email protected]
class: center, middle
- Behave good! Do not do things or say things that you would not do in front of your grandmother on a Sunday's coffee table.
- What I condensed from your knowledge maps
- Different roles and stakeholders?
- Process that consists at least of implementation and maintenance?
- 2/3-tier architecture?
- Use of UML. Are you sure about this?
- What I condensed from your ignorance maps
- How does one know that it works as intended?
- How is it tested and debugged?
- Who/which roles made the app precisely?
- Exact process (stages and iterations?) and tools involved in its creation?
- Precise requirements and goals of product?
- Frequency and timeframe for maintenance tasks?
- Precise structure and components of application?
- How to figure out and how to capture what a software system is supposed to do. (Requirements engineering and analysis)
- How to design a software system's architecture and internals (Design and application of patterns and design guidelines).
- How to communicate about a software system (UML).
- How to test, build, and package a software system.
- How to create software (Software development processes).
class: center, middle
We are in a course "Analysis, Design and Software Architecture".
We have to get an idea about what we are doing in this course. That is, we have to better understand these terms:
"Analysis①, Design② and Software⓪ Architecture③".
Interestingly, it is not properly defined what software actually is.
--
Common definitions are not too helpful:
"[software are] the programs and other operating information used by a computer."
Oxford Dictionary of English
- Stakeholders negotiating and signing software sourcing contracts are often generalists.
- The contracts that they sign have to specify what is a deliverable and what is not.
- This is where the question arises: "What shall be considered software, i.e., what precisely are the artifacts to be delivered?"
--
- There are cases where customers got delivered a systems' source code without a complete build specification and without the built executable. Since source code alone is unusable, build code as well as executables should be considered constituents of software.
"computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system [...]"
828-2012 - IEEE Standard for Configuration Management in Systems and Software Engineering, 2012
--
"all or a part of the programs, procedures, rules, and associated documentation of an information processing system. [...] it is typically important to include both executable and non-executable software, such as fonts, graphics, audio and video recordings, templates, dictionaries, documents and information structures such as database records."
ISO/IEC 19770-5:2015(en) Information technology - IT asset management, 2015
--
"all or part of the programs which process or support the processing of digital information
[...] For the purposes of this definition, software excludes information per se, such as the content of documents, audio and video recordings, graphics, and databases.
[...] There is both executable and non-executable software. The purpose of non-executable software is to control or support executable software, and includes, for example, configuration information, fonts, and spell-checker dictionaries. Digital information which is managed by executable software (e.g. the content of documents and databases) is not considered software [...] , even though program execution may depend on data values."
ISO/IEC 19770-1:2017(en) Information technology – IT asset management, 2017
- In some countries public agencies use prescribed standard contracts when sourcing software, e.g., the Danish standard contracts (K01, K02, and K03) and the British Model Services Contract.
- Definitions -if given- are recursive and inconclusive.
- MSC & K01 do not explicitly define of the term software.
- K02 & K03 define it recursively.
--
Software
Consists of Customer-specific Software and/or Standard Software. Also includes interfaces.
--
Customer-specific Software
Software that is not classified [...] as Standard Software.
--
Standard Software
[...] is neither customized, adapted, nor developed specifically for the customer in connection with the supplier's fulfillment of the contract, and partly available to anyone on ordinary commercial or non-commercial and equal terms.
Of what remind you the definitions of software in K02 and K03?
Software
Consists of Customer-specific Software and/or Standard Software. Also includes interfaces.
Customer-specific Software
Software that is not classified [...] as Standard Software.
Standard Software
[...] is neither customized, adapted, nor developed specifically for the customer in connection with the supplier's fulfillment of the contract, and partly available to anyone on ordinary commercial or non-commercial and equal terms.
--
Sommerville says there are two kinds of software products:
- Generic products These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. [...]
- Customized (or bespoke) software These are systems that are commissioned by and developed for a particular customer. A software contractor designs and implements the software especially for that customer. [...]
-
Definitions -if given- are inconclusive or mere lists of exemplary artifacts:
[...] software is not just the programs themselves but also all associated documentation and configuration data that is required to make these programs operate correctly. [...] It may include system documentation, [...] user documentation, [...] and websites for users to download recent product information."
Sommerville "Software Engineering" (9th Ed.)
--
[...] software is not just the programs themselves but also all associated documentation, libraries, support web-sites, and configuration data that are needed to make these programs useful. [...] It may include system documentation, [...] user documentation, [...] and websites for users to download recent product information.
Sommerville "Software Engineering" (10th Ed.)
--
- Real software runs on computers. It is a sequence of ones and zeros that is stored on some magnetic media. It is not a program listing in C++ (or any other programming language).
- A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
J. Reeves "What is Software?"
-
Definitions are unpractical:
"[...] software is pattern per se, or syntactical form [...] Hardware, in short, is also software, but only because everything is."
P. Suber, "What is software?" The Journal of Speculative Philosophy, pp. 89–119, 1988.
- Imagine, we have a computer based on the 6502 microprocessor
Address Machine Code Assembly
-----------------------------------
$0600 a9 0f LDA #$0f
$0602 69 02 ADC #$02
$0604 85 00 STA $00
You can examine the example above at the online simulator: Source https://skilldrick.github.io/easy6502.
- Now, imagine we want to change the behavior of our system so that the number two is subtracted instead of added.
- Software engineers would likely change the program to the following:
Address Machine Code Assembly
-----------------------------------
$0600 a9 0f LDA #$0f
$0602 e9 02 SBC #$02
$0604 85 00 STA $00
- Now, imagine we want to change the behavior of our system so that the number two is subtracted instead of added.
- We could also just replace the processor with a custom variant, in which we change the internal wiring so that processor's opcode
$69becomes$e9.
"Software is the collection of all artifacts, which allow (a) suitably educated person(s) with access to specified and suitable hardware to instantiate a running system.
Additionally, the collection of such artifacts allow such suitably educated person(s) to understand and reason about a systems' working and properties and let them understand why the system is as it is and why it behaves the way it does."
Helge
class: center, middle
--
- Analysis
- Noun/verb method for class and method identification
- CRC (class/responsibilities/collaborators) cards with scenarios for analysis
--
↑ Is this a design of a vase actually?
--
↓ that is the actual design according to Jack Reeves https://cdn.thingiverse.com/assets/24/31/cb/7c/50/VaseV650.stl
Source A vase from Thingiverse.class: center, middle
use of scientific principles, technical information, and imagination in the definition of a software system to perform pre-specified functions with maximum economy and efficiency
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
--
In every engineering discipline, design encompasses the disciplined approach we use to invent a solution for some problem, thus providing a path from requirements to implementation. In the context of software engineering, Mostow suggests that the purpose of design is to construct a system that:
- Satisfies a given (perhaps informal) functional specification
- Conforms to limitations of the target medium
- Meets implicit or explicit requirements on performance and resource usage
- Satisfies implicit or explicit design criteria on the form of the artifact
- Satisfies restrictions on the design process itself, such as its length or cost, or the tools available for doing the design
G. Booch et al. "Object-Oriented Analysis and Design with Applications"
--
That is similar to what Sommerville says about Software Engineering:
Engineering discipline Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work within organizational and financial constraints, and they must look for solutions within these constraints.
The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. [...] the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.
J. Reeves "What is Software?"
--
Note, other more object-oriented analysis and design advocates have a slightly other opinion on that:
Design involves balancing a set of competing requirements. The products of design are models that enable us to reason about our structures, make trade-offs when requirements conflict, and in general, provide a blueprint for implementation.
G. Booch et al. "Object-Oriented Analysis and Design with Applications"
But if we consider software engineers to be the "users" of our code, we design for them, for example when designing classes, methods, their interfaces, etc.
static public bool IsValid(string path)
{
Ensure.ArgumentNotNull(path, "path");
if (string.IsNullOrWhiteSpace(path))
{
return false;
}
try
{
Proxy.git_repository_open_ext(path, RepositoryOpenFlags.NoSearch, null);
}
catch (RepositoryNotFoundException)
{
return false;
}
return true;
}Actually, we design in the small (as on the previous slide) and in the large, see below:
--
- Git
- Implemented in C
- Procedural design
- Gitlet
- Implemented in JavaScript
- Procedural design (quite particular functions attached to a hashmap)
- WYAG
- Implemented in Python
- Hybrid procedural and object-oriented design
- libgit2sharp
- Implemented in C#
- Object-oriented design
class: center, middle
Architecture represents the set of significant design decisions that shape the form and the function of a system, where significant is measured by cost of change.
--
Architecture is about the important stuff. Whatever that is”. On first blush, that sounds trite, but I find it carries a lot of richness. It means that the heart of thinking architecturally about software is to decide what is important, (i.e. what is architectural), and then expend energy on keeping those architectural elements in good condition. For a developer to become an architect, they need to be able to recognize what elements are important, recognizing what elements are likely to result in serious problems should they not be controlled.
--
Combining the concept of the class and object structures together with the five attributes of a complex system (hierarchy, relative primitives [i.e., multiple levels of abstraction], separation of concerns, patterns, and stable intermediate forms), we find that virtually all complex systems take on the same (canonical) form, [...]. Collectively, we speak of the class and object structures of a system as its architecture.
G. Booch et al. "Object-Oriented Analysis and Design with Applications"
Software Architecture — Git
Spend ten minutes to inspect Gitlet and Git.
- Can you describe the architecture of Gitlet? How does it look like?
- Can you describe the architecture of Git? How does it look like?
Software Architecture — Git
class: center, middle
Designing software is an exercise in managing complexity. The complexity exists within the software design itself, within the software organization of the company, and within the industry as a whole. Software design is very similar to systems design. It can span multiple technologies and often involves multiple sub-disciplines.
Software specifications tend to be fluid, and change rapidly and often, usually while the design process is still going on.
Software development teams also tend to be fluid, likewise often changing in the middle of the design process. In many ways, software bears more resemblance to complex social or organic systems than to hardware. All of this makes software design a difficult and error prone process.
J. Reeves "What is Software?"
Software systems are abstract and intangible. They are not constrained by the properties of materials, nor are they governed by physical laws or by manufacturing processes. This simplifies software engineering, as there are no natural limits to the potential of software. However, because of the lack of physical constraints, software systems can quickly become extremely complex, difficult to understand, and expensive to change.
Sommerville "Software Engineering" (10th Ed.)
--
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
[...] inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility
F.P. Brooks "No Silver Bullet—Essence and Accident in Software Engineering"
- The problem domain (also called application domain) is difficult. The solution domain is difficult.
B. Brügge et al "Object-Oriented Software Engineering: Using UML, Patterns, and Java"
- Jack Reeves talks about problem and software space
- D. J. Barnes et al. call it the problem and solution domain too.
Loven på skatteområdet er så kompleks, at det ikke er forsvarligt at løse nogle af de helt centrale problemer i skattevæsenet med en videreudvikling af PSRM
- the complexity of the problem domain,
- the difficulty of managing the development process,
- the flexibility possible through software,
- and the problems of characterizing the behavior of discrete systems.
G. Booch et al. "Object-Oriented Analysis and Design with Applications"
--
Software systems are discrete state systems that do not have the repetitive structure found in computer circuitry. There is seldom a good reason to construct software as highly repetitive structures. The number of states in software systems is orders of magnitude larger than the number of states in the nonrepetitive parts of computers. [...] This [...] clearly contributes to the relative unreliability of software systems and the apparent lack of competence of software engineers. It is a fundamental difference that will not disappear with improved technology
The topics in the remainder of this course are meant to make software design and development more easy and manageable.
- Go to the exercise session.
- Work on assignment 00, see https://github.com/itu-bdsa/assignment-00/README.md
Via LearnIT Hand-in, hand-in a link to the Git repository on GitHub with your solution, at latest next Friday at 10:00.
Guest lecture/workshop series with
 |
 |
|---|
- 13/9 Version Control with Git
- 20/9 Containerization with Docker
- 27/9 Continuous integration with GitHub Actions
Always from 16:00-20:00 in rooms 4A14-16