Welcome to your wiki!

http://sourceforge.net/userapps/mediawiki/henriksorensen

The wiki uses Markdown syntax.

Project Members:

• Henrik Sorensen (admin)

Architecture and Design

• [AnnotatedArchitectureTemplate] - A template for Architecture documents, with comments in the sections.
• [ArchitechtureConcepts] - Describes how to write an architecture document.
• [ConceptsAndPrinciples]
• UML views (4+1)
  • (See alseo: http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/rdiagtype.html)
  • [UseCases] - There are always the use cases.
  • ''Logical view''; abstract descriptions of a system’s parts.
    • [StateDiagrams] - A description of what state diagrams are and the concepts for creation.
    • [MessageSequenceChart] - Sequence diagrams are all about capturing the order of interactions between parts of your system.
    • [CommunicationDiagram] - model the dynamic behavior of the use case. Represent a combination of information taken from ClassDiagram, Sequence, and UseCases describing both the static structure and dynamic behavior of a system.
    • [TimingDiagram]
    • [InteractionOverviewDiagram] - Similar to the ActivityDiagram, in that both visualize a sequence of activities. The difference is that, for an interaction overview, each individual activity is pictured as a frame which can contain a nested interaction diagrams.
    • [ClassDiagram]
    • [ObjectDiagram]
    • [CompositeStructureDiagram] - Static structure diagram, that shows the internal structure of a class and the collaborations that this structure makes possible.
  • ''Process view''; Describes the processes within your system.
    • [ActivityDiagram] -
  • ''Development view''; The development view describes how your system’s parts are organized into modules and components and is great at helping you manage layers within your system’s architecture(Rus06,p186).
    • [ComponentDiagram]
    • [PackageDiagram] - Package diagrams are often used to view dependencies among packages.
  • ''Physical view''; Describes how the system’s design, as described in the three previous views, is then brought to life as a set of real-world entities.
    • [DeploymentDiagram] - show the physical view of your system, bringing your software into the real world by showing how software gets assigned to hardware and how the pieces communicate(Rus06, p224)
  • [ProtocolDocumentation]- A description of how to describe communcation protocols.
  • [PughMatrix]
  • [QualityAttributes]
  • [ContextModel] - Context Model/Context Diagram.
• Design tools
  • Visio

• Reverse engineering

  • [ReverseEngineerFromCodeToArchitechture] - Describes a process of getting from source code to architecture.

• From Idea to Product

  • [IdeaCapture] - describe the idea and investigate its 'worthiness' to be implemented.
  • [InitialCharter] - get started reflecting on the opportunities.
  • [InitialFinancialEstimate] - Get an idea about what the monetary cost and gain might be.
  • [FullCharter] - Rough plan/description of the project and the ROI of it.
    • TODO: write about how to fill this in
    • the flows of information that enter and leave a piece of work actually define its scope(Rob06).
    • we can define your work as processing the information and transforming it into a requirements specification. This important idea of defining work and its boundaries by defining the inputs and outputs will be revisited several times in this book(Rob06,ch3).
    • Setting the scope of the work means that you determine what work you are about to study, what other pieces of work surround it, and what flows of information make up the connections. When you set the scope, you are deciding how much of the work you will study and what you will not study(Rob06,ch3).
  • [BlastOff] - Starting off the project, with Context diagram, business events and BusinessUseCase.
    • [BusinessEvent]
    • [BusinessScenario]
    • [ProblemDomain]
  • [FeatureImplementationPlan] - this is the initial freestyle captuing of how to implement the idea. With the pro's and cons of the various possible solutions to challenges. This is to allow the desginer a chance to think through the whole solution without being constrained to a specific document format.
    • Games: [TemplateCTaylorGameDesign]
    • [GenericFeatureImplementationPlan]
  • [ArchitechtureConcepts] - document the architecture.
  • [DesignPatterns] - GoF +
  • [TechnicalRequirementsSpecification]
    • [RequirementHandling] - Also include requirement patterns.
  • [SystemRequirementsSpecification]
  • [TestPlan]
  • [LeanDevelopment]
  • [ContinuousIntegration]

• General document writing process

  • [CommunicatingClearly]

• [QuickReferenceVersionSystems]

  • Read the background brief, or talk to the customer
  • Look into current product
    • If it is SW: Look through the source code that is to be changed, to find the areas that has to be changed.
    • If it is services: Get hold of a small environment with the service apps, and play with them, to get a feel for it. Look at the aspects that are to be changed.
  • Discover the Use cases.
  • Discuss the Use cases with the Primary stakeholders.

[MicroServices]

[PrinciplesOfTeaching]