Goals and Constraints

Why do we need a SimStadt software architecture?

A main outcome of project SimStadt will be a software for computing energy flows at the city level as well as for city districts and single buildings based on 3D city models. To successfully design, implement, deploy, and run a non-trivial piece of software in an interdisciplinary group over several years requires a common understanding of its architecture. But what is a software architecture anyway. In short:

• The software architecture describes a solution, that is how to proceed from requirements to implementation
• A software architecture describes the high level structure of the system, that is its building blocks, interfaces, and other relations. It does so from different point of views, mainly:
  • Context view (bird's eye view)
  • Composition view (building blocks)
  • Run time view (interplay of components in the running system)
  • Infrastructure view (environment to run the software)
• The software architecture it is an important part of a project's documentation
• As such, it advances the common understanding of the people involved.

Development of the SimStadt software and architecture starts with certain requirements and given constraints. Thus, we have to develop a common understanding of:

• functional requirements (what to compute)
• non-functional requirements (e.g. flexibility, performance, maintainability)
• and given constraints (available time, developer skills, legal aspects to name a few).

While users and domain experts usually focus on functional requirements, architects and developers have to deal with the other two a lot in order to get the system going with a certain degree of quality. For example, a qualitative requirement for SimStadt could be, that a guest scientist may learn the technicalities required to add a new simulation algorithm to the system in not more than three days.

Besides requirements, the systems architecture strongly depends on how cross-cutting technical aspects are dealt with, including:

• Persistence
• Integration of and communication between subsystems
• Workflow, organizational processes
• User interfaces
• Exception handling
• Security
• Internationalization
• Logging

The structure of the architecture wiki pages is an adaption of an established template developed by experienced software architects (see arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.). It contains expandable sections with valuable tips, questions, forms, examples that will help us to gather all information relevant for developing the SimStadt architecture and software.

Short description of functional requirements

How to

Digest (or abstract) of the requirements documents. Reference to complete requirements documents (incl. version identification and location).

Contents

A compact summary of the functional environment of the system. Answers the following questions (at least approximately):

• What happens in the system’s environment?
• Why should the system exist? Why is the system valuable or important? Which problems does the system solve?

Motivation

From the point of view of the end users a system is created or modified to improve execution of some activity. This essential architecture driver must not be neglected.

Form

Short textual description, probably in tabular use-case format.

Examples

Short descriptions of the most important:

• (business) processes
• functional requirements
• non-functional requirements and other constraints (the most important ones must be covered as architecture goals or are listed in the “Constraints” section) and/or
• quantity structures
• background information

Here you can reuse parts of the requirements documents – but keep these excerpts short and balance readability against avoidance of redundancy.

Quality goals

How to

Contents

The top three (max five) goals for the architecture and/or constraints whose fulfillment is of highest importance to the major stakeholders. Goals that define the architecture’s quality could be:

• availability
• modifiability
• performance
• security
• testability
• usability

Form

Simple tabular representation, ordered by priorities

Background Information

NEVER start developing an architecture if these goals have not been put into writing and have not been signed by the major stakeholders.

Stakeholders

How to

Contents

A list of the most important persons or organizations that are affected by or can contribute to the architecture.

Motivation

If you do not know the persons participating in or concerned with the project you may get nasty surprises later in the development process.

Form

Simple table with role names, person names, their knowledge as pertaining to architecture, their availability, etc.

Technical constraints

How to

Contents

List all technical constraints in this section. This category covers hard- and software infrastructure, applied technologies (operating systems, middleware, databases, programming languages, …).

Examples

Constraint	Description
Hardware infrastructure	Processors, memory, networks, firewalls and other relevant elements
Software infrastructure	Operating systems, database systems, middleware, communications systems, transaction monitors, web servers, directory services
System operations	Batch- or online operations of the system or of required external systems?
Availability of the runtime environment	Data center with 7x24 uptime? Will there be service times that cause reduced availability of the system or important parts thereof?
Graphical user interface	Are there any restrictions related to GUI (style guide)?
Libraries, frameworks, components	Is there any components-off-the-shelf (COTS) that must be used?
Programming languages	Object oriented, structured, declarative, or rule-based languages? Compiled or interpreted languages?
Reference architectures	Are there any comparable or reusable reference projects?
Analysis and design methodologies	Object oriented or structured methodologies?
Data structures	Requirements for certain data structures, interfaces to existing databases or files?
Software interfaces	Interfaces to existing applications
Programming requirements	Programming guidelines, fixed program structure
Technical communications	synchronous or asynchronous; protocols

Constraint	Description
Hardware infrastructure	Users and developers will use standard Windows-PCs (Linux and Macs may be added later) for accessing the locally installed Simstadt software and data. This software will often access simulation and data services installed on several Servers maintained by project partners. Probably, novaFactory will run on servers at M.O.S.S. and HfT, Stanet at HfT, and INSEL at doppelintegral and HfT. Any central data repository will be hosted at HfT. If required, a pool of high performance graphics workstations is available at HfT as client machines (and possibly as number crunching servers). Hand held devices may be considered for data acquisition by researchers or "crowd sourcing".
Software infrastructure	Client machines will run under Windows 7 and 8. Servers may run under Windows Server or Linux. Probably, MySQL will serve as relational database management system on server and client. Tomcat 7 or Glassfish 4 are suitable open source web application servers. Besides novaFactory, INSEL and Stanet, proprietary software packages shall not be used. E.g., Matlab shall not be considered.
Availability of the runtime environment	Web and data services should be accessible around the clock. However, data and computation intensive tasks may block servers for some minutes or so. Suited strategies for load balancing will be considered when required.
Graphical user interface	TBD: Are there any restrictions related to GUI (style guide)?
Libraries, frameworks, components	On the simulation side STANET® will be used for simulating heat distribution networks, while INSEL® will provide simulation components for meteorology, renewable energy systems and building physics. Special algorithms, e.g. radiosity algorithms, are accessible in CitySim. City GML data will be provided and processed by novaFactory, ArcGIS, and Google SketchUp.
Programming languages	Team skills, availability of a wide range of free libraries as well as software development already done in preliminary projects suggests the use of Java for heavy programming tasks (JavaSE for client side, and JavaEE, Web profile for server side programming). Scripting languages of choice are Ruby and Python. Considering the time horizon of the project, the very latest releases of programming languages and libraries should be used, that is JavaSE 8 (still beta, but feature complete), Java EE 7, Ruby 2.0, and Python 3.3. Note that programming specialized INSEL-Blocks currently has to be done in Fortran. A crowd sourcing approach may require development of browser based web apps or even special apps for hand held devices.
Reference architectures	A SimStadt-like integrated system for simulation and assessment of urban energy flows is not available today. Fields like ecology, genomics, physics and geoscience have to deal with scientific computation and simulation tasks of similar kind, so solutions developed here may be transferrable. Similar, looking at Business Intelligence systems and other means of dealing with "big data" may be helpful.
Data structures	CityGML will be used for importing and storing building and other geographic data. A CityGML energy ADE has to be designed to enrich the geographic data with domain specific data about energy generation, consumption, and distribution.
Software interfaces	Interfaces to external applications like Stanet, INSEL, SketchUp, and others are documented in the Software interfaces section of the requirements document.
Programming requirements	TBD: Programming guidelines, fixed program structure
Technical communications	Communication with Stanet and INSEL models will be via file interfaces and command line calls, probably encapsulated as web service.

Organizational constraints

How to

Contents

Enter all organizational, structural, and resource-related constraints. This category also covers standards and legal constraints that you must comply with.

Example

Constraint	Description
Organization and Structure
Project team’s organizational structure	with/without subcontractors, decision-making power of the project manager
Decision makers	Experience with similar projects
Existing partnerships or co-operations	Are there any co-operations between the organizations and certain software companies? Such partnerships often influence procurement decisions (independent of system requirements).
Internal development or outsourcing	Develop internally or outsource to external service companies?
Development of a product or for internal use?	Implies different processes in requirements analysis and decision making. In the case of product development: New product for a new market? Improved product for an existing market? Productizing of an existing (internal) system? Development for internal use only?
Resources (Budget, Time, Personnel)
Schedule	Is the schedule flexible? Is there a fixed delivery date? Which stakeholders control the delivery date?
Schedule vs. functionality	What has higher priority: The delivery date or the functionality?
Release-schedule	At which dates should which functionality be available in which releases / versions?
Project’s budget	Fixed or flexible? What amount is available?
Budget for technical resources	Buy or rent development tools? (hardware and software)
Team	Number of team members, qualifications, motivation, availability.
Organizational Standards
Development process	Requirements concerning development process? This includes internal standards for modeling, documentation and implementation.
Development tools	Requirements related to development tools (such as CASE-Tool, database, IDE, communications software, middleware, transaction monitor).
Configuration and version management	Requirements concerning processes and tools
Test tools and processes	Requirements concerning processes and tools
Acceptance- and release processes	Data modeling and database design User interfaces Business processes (workflow) Usage of external systems (e.g. write access to external databases)
Service Level Agreements	Requirements or standards related to availability or required service levels?
Legal Factors
Liability	Are there any legal aspects related to usage or operations of the system? Could the system cause loss of human life or hazard to human health? Could the system impact the operations of external systems or businesses?
Data privacy and security	Does the system store or process any data worthy of protection
Auditing	Are any aspects of the system under legal obligation to present evidence?
Aspects of international law	Will the system be used in an international context? Are there varying constraints on system usage in different countries (example: use of encryption technology)?

Conventions

How to

Contents

List all conventions that are relevant for the development of your software.

Form

Either insert the conventions directly in this document or refer to other documents.

Examples

• Coding guidelines
• Documentation guidelines
• Guidelines for version and configuration management
• Naming conventions