Categories

mcpd 70-549 notes

Here my notes taken while reading for the exam.

Chapter 1 – Evaluating the Technical Feasibility

  • Types of requirements: Business, user, functional and QoS.
  • Use-cases are not requirements but detail the process of a certain requirement.
  • Evaluation of requirements: Feasible, complete, unambiguous and necessary.
  • Client technologies: Windows, smart, browser-based, AJAX enabled, Microsoft Office and mobile.
  • Remote communication: Web services vs. .NET remoting.
  • Data storage. Check out the versions of SQL server http://microsoft.com/sql: Express, Standard, Enterprise, Everywhere.
  • Existing solutions: Corporate assets, 3rd party, BizTalk server, Host Integration server, SharePoint services, Commerce server.
  • Prototype to fill the gap between requirements and current knowledge.
  • Proof-of-concept. Vertical slice of application.
  • Mock-up. Horizontal slice of the application – UI only.
  • Use a prototype to verify critical design decisions and to create application container guidance for the developers.

Chapter 2 – Creating Specifications for Developers

  • Logical model to create common understanding of the application domain. Can be modelled with object role modelling (ORM).
  • ORM object: Nouns.
  • ORM relations: Association of ORM objects.
  • ORM facts: Verbs.
  • ORM constratins. Mandatory (filled circle)/not mandatory and multiplicity: One-to-many, many-to-one, one-to-one, many-to-many.
  • User interface layer. Can be subdivided into: Presentation, User interface code, Business logic interaction code.
  • Middle tier. Can be subdivided into: Business layer, Application layer, Database layer.
  • Database layer. Can be subdiveded into: Database layer, Stored procedures, Integration services, Database tables, log and indexes.
  • Communication between layers: Soap/Http, TCP/IP, in process, named pipes.
  • Component diagram: Packages of components reflecting the logical layers. Packages are group by nodes. A node represents a deployment container.
  • Class, sequence and activity diagrams.
  • Database normalization: 1NF, 2NF, 3NF and 4NF.
  • ER diagrams (normal database diagrams in Visio).

Chapter 3 – Design Evaluation

  • Evaluate the logical design for: Performance, scalability, availability, security, maintainablility, extensibility, data integration and business use-case.
  • Evaluate the logical design to verify that the requirements and vision are met. Also ensure that it can mature as a product.
  • Evaluate the physical design for: Performance, scalalbility, availability, security, maintainability, extensibility and data integration.
  • Evaluate the physical design to verify that the requirements are met.

Chapter 4 – Component Design

  • Database design. Use the ORM diagram to identity database tables and model relationships with foreign keys. Add primary keys to obain unique IDs for the rows and an index to faster retrieve items.
  • Refine the database design through: Secondary indexing, data consistency and concurrency management (eg. SQL Server timestamps).
  • Component design. Place the componets and create high-level design: Life-cycle considerations and design pattern identification.
  • Design interfaces (API) for your components. Determine whether functionality can be inherited from a existing component. Assign features to the components.

Chapter 5 – Component Development

  • Decide whether to extend, compose or implement a feature.
  • Consider whether to build a stateful component and multithreading. Thread safety can be expensive to implement.
  • IDisposable interface is used to handle unmanaged resources. Wrap calls to a class implementing it with a using statement. When keep a reference to a class with IDisposable longer than a single call you should also implement IDisposable.
  • Data access methologies:
    • DataReader and Command. When performance and scalability are most important. Highest development effort.
    • DataSet. For a good mix of scalability and development cost. Lower performance.
    • Typed DataSet. For RAD and prototyping.
  • Exception handling. Do not throw exceptions during normal operation. Enrich exceptions when meaningful. Inhert from System.Exception for custom exceptions.

Chapter 6 – Multimedia in Distributed Applications

  • Delivery of binary data via web services:
    • Binary Data by Value. Binary data is placed within the XML document encoded into some MIME format (eg. base64). This creates potentially large XML messages.
    • Binary Data by Reference. Binary data is placed outside the XML. This way you cannot apply standard encryption to the messages.
    • Direct Internet Message Encapsulation – DIME. Use it’s own format with a header (data records). The message as such is not a well-formed XML document.
    • Message Transmission Optimization mechanism (MTOM). Uses XML-Binary Optimized Package (XOP) to send binary data in the XML message but not base64 encoded. This requires MTOM on client and server to convert a SOAP message to MTOM and back.
    • Streaming. Custom implementation of IXmlSerializable or using WSE 3.0.
    • As alternative a Message Queue can be used to send binary data. Is restricted to .NET.
    • Bandwith of AV data can be reduced by sampling rate, compression, resolution or frame rate.

  • Chapter 7 – Reusable Software Components

  • To reuse existing components inheritance can be applied to adapt the component to your needs.
  • Know the access levels: public, private, protected, internal, protected internal.
  • Abstract class cannot be instantiated. If one or more methods are marked as abstract the containing class must be marked as abstract as well.
  • Public methods are by default not overridable. Mark with virtual to override those.
  • To redefine a method in an inherited class use the new keyword. Also called hiding by name.
  • Pitfalls of extending components: Deep inheritance chains and exessive overriding.

Chapter 8 – Design Logic Implementation

  • Development methodologies: Waterfall and agile.
  • Layers are boundaries in your code (eg. assembly) while tiers a physical locations of where the code is executing.
  • Layer responsiblities.
    • Presentation. Display information and collect user input.
    • Application Logic. Process data.
    • Data Access. Interaction with data store, file system and remote systems.
  • Typical 3-layer system: Presentation layer with MVC pattern, Application logic layer with facade pattern and DAL using provider pattern.
  • Data storage mechanisms: Registry, app.config, XML files, plain-text files, database and message queuing.
  • Dataflow with ADO.NET vs. OR mapping.
  • Design either stateful or stateless.
  • Try to achieve loose coupling but pay attention to performance issue when using services and remoting.
  • Know about authentication and authorization.

Chapter 9 – Logging and Monitoring

  • Logging is targeted for developers, auditors and security group.
  • Logging should cover general application health, performance and security auditing with adjustable level of detail.
  • Typical logging categories: Error, Warning, Information, Failure Audit, Success Audit.
  • Logging storage: Flat file, event log and database.
  • Monitoring is targeted for operations and security group.
  • Monitoring storage: E-mail, performance counters.
  • You can use the Logging Application Block from Enterprise Library for logging and monitoring.

Chapter 10 – Planning for Testing

  • Most of this chapter is useless.
  • Definition of test case, test suite and test fixture.
  • Properties of good unit test: Clear, independent, fast, isolated and limited in scope. The difference between independent and limited in scope is not really clear. The independent criteria seems misunderstood because it means that any two unit test should not be dependent on each other.
  • What methods to test: Public and protected. Private – if necessary – using reflection to call the method.
  • Integration testing tests a collection of classes after their unit tests have passed.
  • Notice the following integration testing strategies:
    • Top-Down. Starts on the highest level. Advantage: Minimizes need for drivers. Disadvantages: Increases need for stubs and does not allow to test a single feature.
    • Bottom-Up. Starts on the lowest level. Advantage: Minimizes need for stubs. Disadvantages: Increases need for drivers and does not allow to test a single feature.
    • Umbrella/Vertical Slice. Testing occurs along the functional and control-flow lines. Advantages: Minimizes need for drivers, stubs and tests single feature. Disadvantage: The integration points are difficult to identify.
  • Know the difference between performance and stress testing.
  • Test and production environment should be as much alike as possible (this is too expensive in most cases!).
  • Generate random test data with Visual Studio or custom code.

Chapter 11- Unit Testing

  • What should be tested:
    • Inspect the methods and properties of a class. Test with good, critcal and failing data.
    • Derive the unit tests from the use cases.
  • Code coverage is not everything. But as rule of thumb should  be  between 80 and 100 %.
  • Black-box testing does not start with the implemented class but from a requirements perspective looking at input and output.
  • White-box testing does not focus on the individual features but ensures that an added component does not affect the applicaiton.
  • Data-driven testing with MS-Test can be used to create parameterized unit tests. Eg. the test and expected result data can be read from an Excel spreadsheet.
  • Components can be isolated by using mock or stub objects.

Chapter 12 – Stablizing the Application

  • Code review techniques: Inspection, code walkthroughs, pair programming, over the shoulder review.
  • Scope of code reviews: Design, coding standards, maintainability, documentation, security, performance.
  • An integration test is a piece of code that combines several units of code and tests their integration.
  • Integration test steps: Create test plan, run use case test, run load test, run stress test, run globalization test and run security test.

Chapter 13 – Evaluating Application Performance

  • Model application performance in order to be able to create performance targets that can be used throughout the entire development cycle.
  • Monitoring tools: Windows Performance Monitor, Microsoft Operations Manager (MOM), Network Monitor.
  • Profiling tools: CLR Profiler, SQL Server Profiler, VS 2005 Performance Explorer.
  • Instrumentation: Enterprise Instrumentation Framework, Debug class, Trace Class.
  • Security monitoring: Baseline Security Analyzer,  IP Security Monitor.
  • Deployment plan should describe:
    • Target environments
    • Resource requirements
    • Configuration requirements
    • Possible deployment issues
    • Responsiblity for deploying and hosting
    • Integration to external systems
  • Application flow diagram depicts the interaction and relations between components (typically assemblies).
  • An applicaitons complexity can be measured with the cyclomatic complexity: C = E – N + P.
    • E – number of dashed lines in diagram, N – number of components, P – number of components that depend on other components.
    • 1-10: Simple, 11-20: Moderate, 21-50: Complex, >50: Very complex.

Learning Points

  • One data access component per store.
  • VS Performance session to find performance issues after certain amount of up-time and bottlenecks.
  • Perform integration testing with as much of the developed application. Try to avoid using test clients.
  • Try to bundle web application in one project.
  • User process compentents also belong in presentation layer.
  • Prioritze bugs: UPR = Impact / Effort