Sunteți pe pagina 1din 27

SECURE HASH ALGORITHM The SHA (Secure Hash Algorithm) hash functions refer to five FIPSapproved algorithms for

computing a condensed digital representation (known as a message digest) that is, to a high degree of probability, unique for a given input data sequence (the message). These algorithms are called secure because (in the words of the standard), for a given algorithm, it is computationally infeasible 1) to find a message that corresponds to a given message digest, or 2) to find two different messages that produce the same message digest. Any change to a message will, with a very high probability, result in a different message digest. The five algorithms, denoted SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512, are cryptographic hash functions designed by the National Security Agency (NSA) and published by the NIST as a U. S. government standard. The latter four variants are sometimes collectively referred to as SHA-2. SHA-1 is employed in several widely used security applications and protocols, including TLS and SSL, PGP, SSH, S/MIME, and IPsec. It was considered to be the successor to MD5, an earlier, widely-used hash function. The security of SHA-1 has been somewhat compromised by

cryptography researchers. Although no attacks have yet been reported on the SHA-2 variants, they are algorithmically similar to SHA-1 and so efforts are underway to develop improved alternative hashing algorithms. Due to recent attacks on the SHA-1, "NIST is initiating an effort to develop one or more additional hash algorithms through a public competition, similar to the development process for the Advanced Encryption Standard (AES)."

SHA-1

One iteration within the SHA-1 compression function. A, B, C, D and E are 32-bit words of the state; F is a nonlinear function that varies;
n

denotes a left bit rotation by n

places; n varies for each operation. denotes addition modulo 232. Kt is a constant. The original specification of the algorithm was published in 1993 as the Secure Hash Standard, FIPS PUB 180, by US government standards agency NIST (National Institute of Standards and Technology). This version is now often referred to as SHA-0. It was withdrawn by the NSA shortly after publication and was superseded by the revised version, published in 1995 in FIPS PUB 180-1 and commonly referred to as SHA1. SHA-1 differs from SHA-0 only by a single bitwise rotation in the message schedule of its compression function; this was done, according to the NSA, to correct a flaw in the original algorithm which reduced its cryptographic security. However, the NSA did not provide any further explanation or identify what flaw was corrected. Weaknesses have subsequently been reported in both SHA-0 and SHA1. SHA-1 appears to provide greater resistance to attacks, supporting the NSAs assertion that the change increased the security.

SHA-1 (as well as SHA-0) produces a 160-bit digest from a message with a maximum length of 264 1 bits and is based on principles similar to those used by Ronald L. Rivest of MIT in the design of the MD4 and MD5 message digest algorithms.

Cryptanalysis of SHA-1
In the light of the results on SHA-0, some experts suggested that plans for the use of SHA-1 in new cryptosystems should be reconsidered. After the CRYPTO 2004 results were published, NIST announced that they planned to phase out the use of SHA-1 by 2010 in favour of the SHA-2 variants. In early 2005, Rijmen and Oswald published an attack on a reduced version of SHA-1 53 out of 80 rounds which finds collisions with a complexity of fewer than 280 operations. In February 2005, an attack by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu was announced. The attacks can find collisions in the full version of SHA-1, requiring fewer than 269 operations. (A brute-force search would require 280 operations.) The authors write: "In particular, our analysis is built upon the original differential attack on SHA0 [sic], the near collision attack on SHA0, the multiblock collision techniques, as well as the message modification techniques used in the collision search attack on MD5. Breaking SHA1 would not be possible without these powerful analytical techniques". The authors have presented a collision for 58-round SHA-1, found with 233 hash operations. The paper with the full attack description was published in August 2005 at the CRYPTO conference. In an interview, Yin states that, "Roughly, we exploit the following two weaknesses: One is that the file preprocessing step is not complicated enough; another is that certain math operations in the first 20 rounds have unexpected security problems.".

On 17 Augrust 2005, an improvement on the SHA-1 attack was announced on behalf of Xiaoyun Wang, Andrew Yao and Frances Yao at the CRYPTO 2005 rump session, lowering the complexity required for finding a collision in SHA-1 to 263. In academic cryptography, any attack that has less computational complexity than a brute force search is considered a break. This does not, however, necessarily mean that the attack can be practically exploited. It has been speculated that finding a collision for SHA-1 is within reach of massive distributed Internet search. In terms of practical security, the major concern about this new attack is that it might pave the way to more efficient ones. Whether this is the case has yet to be seen, but a migration to stronger hashes is believed to be prudent. A collision attack does not present the same kinds of risks that a prreimage attack would. Many of the applications that use cryptographic hashes, such as password storage or document signing, are only minimally affected by a collision attack. In the case of document signing, for example, an attacker could not simply fake a signature from an existing documentthe attacker would have to fool the private key holder into signing a preselected document. Reversing password "encryption" (e.g. to obtain a password to try against a user's account elsewhere) is not made possible by the attacks. Constructing a password that works for a given account requires a preimage attack, and access to the hash of the original password (typically in the shadow file) which may or may not be trivial. At the Rump Session of CRYPTO 2006, Christian Rechberger and Christophe De Cannire claimed to have discovered a collision attack on SHA-1 that would allow an attacker to select at least parts of the message.

SHA-1 algorithm

Pseudocode for the SHA-1 algorithm follows:


Note: All variables are unsigned 32 bits and wrap modulo 232 when calculating Initialize variables: h0 := 0x67452301 h1 := 0xEFCDAB89 h2 := 0x98BADCFE h3 := 0x10325476 h4 := 0xC3D2E1F0 Pre-processing: append the bit '1' to the message append k bits '0', where k is the minimum number >= 0 such that the resulting message length (in bits) is congruent to 448 (mod 512) append length of message (before pre-processing), in bits, as 64-bit big-endian integer Process the message in successive 512-bit chunks: break message into 512-bit chunks for each chunk break chunk into sixteen 32-bit big-endian words w[i], 0 i 15 Extend the sixteen 32-bit words into eighty 32-bit words: for i from 16 to 79 w[i] := (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1 Initialize hash value for this chunk: a := h0 b := h1 c := h2 d := h3 e := h4 Main loop: for i from 0 to 79 if 0 i 19 then

f := (b and c) or ((not b) and d) k := 0x5A827999 else if 20 i 39 f := b xor c xor d k := 0x6ED9EBA1 else if 40 i 59 f := (b and c) or (b and d) or (c and d) k := 0x8F1BBCDC else if 60 i 79 f := b xor c xor d k := 0xCA62C1D6 temp := (a leftrotate 5) + f + e + k + w[i] e := d d := c c := b leftrotate 30 b := a a := temp Add this chunk's hash to result so far: h0 := h0 + a h1 := h1 + b h2 := h2 + c h3 := h3 + d h4 := h4 + e Produce the final hash value (big-endian): digest = hash = h0 append h1 append h2 append h3 append h4

Instead of the formulation from the original FIPS PUB 180-1 shown, the following equivalent expressions may be used to compute f in the main loop above:
(0 i 19): f := d xor (b and (c xor d)) (alternative)

(40 i 59): f := (b and c) or (d and (b or c)) (alternative 1) (40 i 59): f := (b and c) or (d and (b xor c)) (alternative 2) (40 i 59): f := (b and c) + (d and (b xor c)) (alternative 3)

RIVEST SHAMIR AND ADLEMAN ALGORITHM In cryptology, RSA is an algorithm for public-key encryption. It was the first algorithm known to be suitable for signing as well as encryption, and one of the first great advances in public key cryptography. RSA is still widely used in electronic commerce protocols, and is believed to be secure given sufficiently long keys and the use of up-to-date implementations.

History
The algorithm was publicly described in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman at MIT; the letters RSA are the initials of their surnames. Apocryphally, it was invented at a Passover Seder in Schenectady, N.Y. Clifford Cocks, a British mathematician working for the UK intelligence agency GCHQ, described an equivalent system in an internal document in 1973, but given the relatively expensive computers needed to implement it at the time, it was mostly considered a curiosity and, as far as is publicly known, was never deployed. His discovery, however, was not revealed until 1997 due to its top-secret classification, and Rivest, Shamir, and Adleman devised RSA independently of Cocks' work. MIT was granted US patent 4405829 for a "Cryptographic communications system and method" that used the algorithm in 1983. The patent expired on 21 Serptember 2000. Since a paper describing the algorithm had been published in August 1977, prior to the December 1977 filing date of the patent application, regulations in

much of the rest of the world precluded patents elsewhere and only the US patent was granted. Had Cocks' work been publicly known, a patent in the US would not have been possible either.

Operation
RSA involves a public and private key. The public key can be known to everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key. The keys for the RSA algorithm are generated the following way: 1. Choose two large random prime numbers and 2. Compute
o

is used as the modulus for both the public and private keys . , and is coprime to ) = 1. ie: and

3. Compute the totient: 4. Choose an integer such that 1 < < share no factors other than 1; gcd( ,
o

is released as the public key exponent ie:

5. Compute to satisfy the congruence relation for some integer .


o

is kept as the private key exponent

Notes on the above steps:


Step 1: Numbers can be probabilistically tested for primality. Step 3: changed in PKCS#1 v2.0 to . instead of

Step 4: A popular choice for the public exponents is = 216 + 1 = 65537. Some applications choose smaller values such as = 3, 5, or 35 instead. This is done to

make encryption and signature verification faster on small devices like smart cards but small public exponents may lead to greater security risks.

Steps 4 and 5 can be performed with the extended Euclidean algorithm; see modular arithmetic.

The public key consists of the modulus encryption) exponent . The private key consists of the modulus

and the public (jor and the private (or

decryption) exponent which must be kept secret.

For efficiency a different form of the private key jcan be stored:


o o

and : the primes from the key generation, and dmq1. : often called dmp1 and

: often called iqmp and are sensitive and are , and allow computation of given . If

All parts of the private key must be kept secret in this form. since they are the factors of

not stored in this form of the private key then they are securely deleted along with other intermediate values from key generation.

Although this form allows faster decryption and signing by using the Chinese Remainder Theorem, it is considerably less secure since it enables side channrel attacks. This is a particular problem if implemented on smart cards, which benefit most from the improved efficiency. (Start with y = xemodn and let the card decrypt that. So it computes yd(mod p) or yd(mod q) whose results give some value z. Now, induce an error in one of the computations. Then gcd(z x,n) will reveal p or q.)

Encrypting messages
Alice transmits her public key ( & ) to Bob and keeps the private key

secret. Bob then wishes to send message M to Alice.

He first turns M into a number ciphertext corresponding to:

<

by using an agreed-upon

reversible protocol known as a padding scheme. He then computes the

This can be done quickly using the method of exponentiation by squaring. Bob then transmits to Alice.

Decrypting messages
Alice can recover procedure: Given , she can recover the original message M. from by using her private key in the following

The decryption procedure works because first . Now, since and Fermat's little theorem yields and . Since and are distinct prime numbers, applying the Chinese remainder theorem to these two congruences yields . Thus, .

Padding schemes

When used in practice, RSA must be combined with some form of padding scheme, so that no values of M result in insecure ciphertexts. RSA used without padding may suffer from a number of potential problems:

The values m = 0 or m = 1 always produce ciphertexts equal to 0 or 1 respectively, due to the properties of exponentiation. When encrypting with low encryption exponents (e.g., e = 3) and small values of the m, the (non-modular) result of me may be strictly less than the modulus n. In this case, ciphertexts may be easily decrypted by taking the eth root of the ciphertext with no regard to the modulus.

Because RSA encryption is a deterministic encryption algorithm i.e., has no random component an attacker can successfully launch a chosen plaintext attack against the cryptosystem, building a dictionary by encrypting likely plaintexts under the public key, and storing the resulting ciphertexts. When matching ciphertexts are observed on a communication channel, the attacker can use this dictionary in order to learn the content of the message.

In practice, the first two problems might arise when sending short ASCII messages, where m is the concatenation of one or more ASCIIencoded character(s). A message consisting of a single ASCII NUL character (whose numeric value is 0) would be encoded as m = 0, which produces a ciphertext of 0 regardless of what e and N are used. Likewise, a single ASCII SOH (whose numeric value is 1) would always produce a ciphertext of 1. For systems which conventionally use small values of e, such as 3, all single character ASCII messages encoded using this scheme would be insecure, since the largest m would have a value of 255, and 2553 is less than any reasonable modulus. Such plaintexts could be recovered by simply taking the cube root of the ciphertext. To avoid these problems, practical RSA implementations typically embed some form of structured, randomized padding into the value m

before encrypting it. This padding ensures that m does not fall into the range of insecure plaintexts, and that a given message, once padded, will encrypt to one of a large number of different possible ciphertexts. The latter property can increase the cost of a dictionary attack beyond the capabilities of a reasonable attacker. Standards such as PKCS have been carefully designed to securely pad messages prior to RSA encryption. Because these schemes pad the plaintext m with some number of additional bits, the size of the unpadded message M must be somewhat smaller. RSA padding schemes must be carefully designed so as to prevent sophisticated attacks which may be facilitated by a predictable message structure. Early versions of the PKCS standard used ad-hoc constructions, which were later found vulnerable to a practical adaptive chosen ciphertext attack. Modern constructions use secure techniques such as Optimal Asymmetric Encryption Padding (OAEP) to protect messages while preventing these attacks. The PKCS standard also incorporates processing schemes designed to provide additional security for RSA signatures, e.g., the Probabilistic Signature Scheme for RSA (RSA-PSS).

Signing messages
Suppose Alice uses Bob's public key to send him an encrypted message. In the message, she can claim to be Alice but Bob has no way of verifying that the message was actually from Alice since anyone can use Bob's public key to send him encrypted messages. So, in order to verify the origin of a message, RSA can also be used to sign a message. Suppose Alice wishes to send a signed message to Bob. She produces a hash value of the message, raises it to the power of d mod n (as she does when decrypting a message), and attaches it as a "signature" to the message. When Bob receives the signed message, he raises the

signature to the power of e mod n (as he does when encrypting a message), and compares the resulting hash value with the message's actual hash value. If the two agree, he knows that the author of the message was in possession of Alice's secret key, and that the message has not been tampered with since. Note that secure padding schemes such as RSA-PSS are as essential for the security of message signing as they are for message encryption, and that the same key should never be used for both encryption and signing purposes.

Security
The security of the RSA cryptosystem is based on two mathematical problems: the problem of factoring large numbers and the RSA problem. Full decryption of an RSA ciphertext is thought to be infeasible on the assumption that both of these problems are hard, i.e., no efficient algorithm exists for solving them. Providing security against partial decryption may require the addition of a secure padding scheme. The RSA problem is defined as the task of taking eth roots modulo a composite n: recovering a value m such that c=me mod n, where (e, n) is an RSA public key and c is an RSA ciphertext. Currently the most promising approach to solving the RSA problem is to factor the modulus n. With the ability to recover prime factors, an attacker can compute the secret exponent d from a public key (e, n), then decrypt c using the standard procedure. To accomplish this, an attacker factors n into p and q, and computes (p-1)(q-1) which allows the determination of d from e. No polynomial-time method for factoring large integers on a classical computer has yet been found, but it has not been proven that none exists. See integer factorization for a discussion of this problem.

As of 2005, the largest number factored by a general-purpose factoring algorithm was 663 bits long, using a state-of-the-art distributed implementation. RSA keys are typically 10242048 bits long. Some experts believe that 1024-bit keys may become breakable in the near term (though this is disputed); few see any way that 4096-bit keys could be broken in the foreseeable future. Therefore, it is generally presumed that RSA is secure if n is sufficiently large. If n is 256 bits or shorter, it can be factored in a few hours on a personal computer, using software already freely available. If n is 512 bits or shorter, it can be factored by several hundred computers as of 1999. A theoretical hardware device named TWIRL and described by Shamir and Tromer in 2003 called into question the security of 1024 bit keys. It is currently recommended that n be at least 2048 bits long. In 1994, Peter Shor published Shor's algorithm, showing that a quantum computer could in principle perform the factorization in polynomial time, rendering RSA and related algorithms obsolete. However, quantum computation is not expected to be developed to such a level for many years.

Practical considerations
Key generation
Finding the large primes p and q is usually done by testing random numbers of the right size with probabilistic primality tests which quickly eliminate virtually all non-primes. p and q should not be 'too close', lest the Fermat factorization for n be successful. Furthermore, if either p-1 or q-1 has only small prime factors, n can be factored quickly by Pollard's p-1 algorithm, and these values of p or q should therefore be discarded as well.

One should not employ a prime search method which gives any information whatsoever about the primes to the attacker. In particular, a good random number generator for the start value needs to be employed. Note that the requirement here is both 'random' and 'unpredictable'. These are not the same criteria; a number may have been chosen by a random process (ie, no pattern in the results), but if it is predictable in any manner (or even partially predictable), the method used will result in loss of security. For example, the random number table published by the Rand Corp in the 1950s might very well be truly random, but it has been published and thus can serve an attacker as well. If the attacker can guess half of the digits of p or q, he can quickly compute the other half (shown by Coppersmith in 1997). It is important that the secret key d be large enough. Michael J. Wiener showed in 1990 that if p is between q and 2q (which is quite typical) and d < n1/4/3, then d can be computed efficiently from n and e. There is no known attack against small public exponents such as e=3, provided that proper padding is used. However, when no padding is used or when the padding is improperly implemented then small public exponents have a greater risk of leading to an attack, such as for example the unpadded plaintext vulnerability listed above. 65537 is a commonly used value for e. This value can be regarded as a compromise between avoiding potential small exponent attacks and still allowing efficient encryptions (or signature verification). The NIST draft FIPS PUB 186-3 (March 2006) does not allow public exponents e smaller than 65537, but does not state a reason for this restriction.

Speed
RSA is much slower than DES and other symmetric cryptosystems. In practice, Bob typically encrypts a secret message with a symmetric algorithm, encrypts the (comparatively short) symmetric key with RSA,

and transmits both the RSA-encrypted symmetric key and the symmetrically-encrypted message to Alice. This procedure raises additional security issues. For instance, it is of utmost importance to use a strong random number generator for the symmetric key, because otherwise Eve (an eavesdropper wanting to see what was sent) could bypass RSA by guessing the symmetric key.

Key distribution
As with all ciphers, how RSA public keys are distributed is important to security. Key distribution must be secured against a man-in-the-middle attack. Suppose Eve has some way to give Bob arbitrary keys and make him believe they belong to Alice. Suppose further that Eve can intercept transmissions between Alice and Bob. Eve sends Bob her own public key, which Bob believes to be Alice's. Eve can then intercept any ciphertext sent by Bob, decrypt it with her own secret key, keep a copy of the message, encrypt the message with Alice's public key, and send the new ciphertext to Alice. In principle, neither Alice nor Bob would be able to detect Eve's presence. Defenses against such attacks are often based on digital certificates or other components of a public key infrastructure.

Timing attacks
Kocher described a new attack on RSA in 1995: if the attacker Eve knows Alice's hardware in sufficient detail and is able to measure the decryption times for several known ciphertexts, she can deduce the decryption key d quickly. This attack can also be applied against the RSA signature scheme. In 2003, Boneh and Brumley demonstrated a more practical attack capable of recovering RSA factorizations over a network connection (e.g., from a Secure Socket Layer (SSL)-enabled webserver). This attack takes advantage of information leaked by the

Chinese

remainder

theorem

optimization

used

by

many

RSA

implementations. One way to thwart these attacks is to ensure that the decryption operation takes a constant amount of time for every ciphertext. However, this approach can significantly reduce performance. Instead, most RSA implementations use an alternate technique known as cryptographic blinding. RSA blinding makes use of the multiplicative property of RSA. Instead of computing cd mod n, Alice first chooses a secret random value r and computes (rec)d mod n. The result of this computation is r m mod n and so the effect of r can be removed by multiplying by its inverse. A new value of r is chosen for each ciphertext. With blinding applied, the decryption time is no longer correlated to the value of the input ciphertext and so the timing attack fails.

Adaptive chosen ciphertext attacks


In 1998, Daniel Bleichenbacher described the first practical adaptive chosen ciphertext attack, against RSA-encrypted messages using the PKCS #1 v1 padding scheme (a padding scheme randomizes and adds structure to an RSA-encrypted message, so it is possible to determine whether a decrypted message is valid.) Due to flaws with the PKCS #1 scheme, Bleichenbacher was able to mount a practical attack against RSA implementations of the Secure Socket Layer protocol, and to recover session keys. As a result of this work, cryptographers now recommend the use of provably secure padding schemes such as Optimal Asymmetric Encryption Padding, and RSA Laboratories has released new versions of PKCS #1 that are not vulnerable to these attacks.

Branch Prediction Analysis (BPA) attacks

Many processors use a Branch predictor to determine whether a conditional branch in the instruction flow of a program is likely to be taken or not. Usually these processors also implement Simultaneous multithreading (SMT). Branch Prediction Analysis attacks use a spy process to discover (statistically) the private key when processed with these processors. Simple Branch Prediction Analysis (SBPA) claims to improve BPA in a non-statistical way. In their paper, "On the Power of Simple Branch Prediction Analysis", the authors of SBPA (Onur Aciicmez, Cetin Kaya Koc and Jean-Pierre Seifert) claim to have discovered 508 out of 512 bits of an RSA key in 10 iterations. This kind of attack requires the spying process to run on the same machine as the cryptographic process processing the private key but the spying process does not need any special privilege on the attacked system.

Requirements Analysis Document Template


Purpose
The results of the requirements elicitation and the analysis activities are documented in the Requirements Analysis Document (RAD). This document completely describes the system in terms of functional and nonfunctional requirements and serves as a contractual basis between the client and the developers.

Audience
The audience for the RAD includes the client, the users, the project management, the system analysts (i.e., the developers who participate in the requirements), and the system designers (i.e., the developers who participate in the system design). The first part of the document, including use cases and nonfunctional requirements, is written during requirements elicitation. The formalization of the specification in terms of object models is written during analysis. We use an example template for a RAD introduced in the book.

Template
Outline 1. Introduction 1.1 Purpose of the system 1.2 Scope of the system the project 1.4 Definitions, acronyms, and abbreviations 1.5 References 1.6 Overview Description The first section of the RAD is an Introduction. Its purpose is to provide a brief overview of the reasons for its development, its scope, and references context to the (e.g., development

1.3 Objectives and success criteria of function of the system and the

reference to the problem statement written by the client, references to existing studies). systems, The feasibility also introduction

includes the objectives and success criteria of the project. 2. Current system The second section, Current

system, describes the current state of affairs. If the new system will replace an existing system, this section describes the functionality

and the problems of the current system. by the Otherwise, new this system section are describes how the tasks supported accomplished now. 3. Proposed system The third section documents the requirements elicitation and the analysis model of the new system. 3.1 Overview The overview presents a functional overview of the system. 3.2 Functional requirements Functional requirements describes the high-level functionality of the system. 3.3 Nonfunctional requirements 3.3.1 Usability 3.3.2 Reliability 3.3.3 Performance 3.3.4 Supportability 3.3.5 Implementation 3.3.6 Interface 3.3.7 Packaging 3.3.8 Legal 3.4 System models 3.4.1 Scenarios 3.4.2 Use case model 3.4.3 Object model 3.4.4 Dynamic model System models describes the scenarios, use cases, object model, and dynamic models for the system. This section contains the complete functional specification, Nonfunctional requirements describes user-level requirements that are not directly related to functionality. This includes usability, reliability, performance, supportability, implementation, interface, operational, packaging, and legal requirements.

3.4.5 User interfacenavigational including mock-ups illustrating the

paths and screen mock-ups

user interface of the system and navigational paths representing the sequence of screens. The subsections Object model and Dynamic model are written during the Analysis activity.

4. Glossary

A glossary of important terms, to ensure consistency in the specification and to ensure that we use the clients terms.

System Design Document Template


Purpose
System design is documented in the System Design Document (SDD). It describes design goals set by the project, subsystem decomposition (with UML class diagrams), hardware/software mapping (with UML deployment diagrams), data management, access control, control flow mechanisms, and boundary conditions. The SDD is used to define interfaces between teams of developers and serve as a reference when architecture-level decisions need to be revisited.

Audience
The audience for the SDD includes the project management, the system architects (i.e., the developers who participate in the system design), and the developers who design and implement each subsystem.

Template

Outline 1. Introduction 1.1 Purpose of the system 1.2 Design goals 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview

Description The purpose of the Introduction is to provide a brief overview of the software architecture and the design goals. It also provides references to other documents and traceability information (e.g., related requirements analysis document, references to existing systems, constraints impacting the software architecture).

2. Current software architecture

The second section describes the architecture of the system being replaced. If there is no previous system, this section can be replaced by a survey of current architectures for similar systems. The purpose of this section is to make explicit the background information that system architects used, their assumptions, and common issues the new system will address.

3. Proposed software architecture

The third section documents the system design model of the new system.

3.1 Overview

The overview presents a birds-eye view of the software architecture and briefly describes the

assignment of functionality to each subsystem. 3.2 Subsystem decomposition Subsystem decomposition describes the decomposition into subsystems and the responsibilities of each. This is the main product of system design. 3.3 Hardware/software mapping Hardware/software mapping describes how subsystems are assigned to hardware and off-the-shelf components. It also lists the issues introduced by multiple nodes and software reuse. 3.4 Persistent data management Persistent data management describes the persistent data stored by the system and the data management infrastructure required for it. This section typically includes the description of data schemes, the selection of a database, and the description of the encapsulation of the database. 3.5 Access control and security Access control and security describes the user model of the system in terms of anaccess matrix. This section also describes security issues, such as the selection of an authentication mechanism, the use of encryption, and the management of keys. 3.6 Global software control Global software control describes how the global software control is

implemented. In particular, this section should describe how requests are initiated and how subsystems synchronize. This section should list and address synchronization and concurrency issues. 3.7 Boundary conditions Boundary conditions describes the startup, shutdown, and error behavior of the system. (If new use cases are discovered for system administration, these should be included in the requirements analysis document, not in this section.) 4. Subsystem services Glossary The fourth section, Subsystem services, describes the services provided by each subsystem in terms of operations. Although this section is usually empty or incomplete in the first versions of the SDD, this section serves as a reference for teams for the boundaries between their subsystems. The interface of each subsystem is derived from this section and detailed in the Object Design Document. OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) Object-oriented analysis and design (OAD) is often part of the development of large scale systems and programs often using the Unified Modeling Language (UML). OAD applies object-modeling techniques to analyze the requirements for a context for example, a system, a set of system modules, an organization, or a business unit

and to design a solution. Most modern object-oriented analysis and design methodologies are use case driven across requirements, design, implementation, testing, and deployment. Use cases were invented with object oriented programming, but they're also very well suited for systems that will be implemented in the procedural paradigm. The Unified Modeling Language (UML) has become the standard modeling language used in object-oriented analysis and design to graphically illustrate system concepts.

Part of the reason for OAD is its use in developing programs that will have an extended lifetime. Object Oriented Systems
An object-oriented system is composed of objects. The behavior of the system is achieved through collaboration between these objects, and the state of the system is the combined state of all the objects in it. Collaboration between objects involves them sending messages to each other. The exact semantics of message sending between objects varies depending on what kind of system is being modeled. In some systems, "sending a message" is the same as "invoking a method". In other systems, "sending a message" might involve sending data via a socket.

Object Oriented Analysis

Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we want to solve by developing an object-oriented (OO) system. The source of the analysis is a written requirement statements, and/or written use cases, UML diagrams can be used to illustrate the statements. An analysis model such will as not take into account implementation persistence, or constraints, concurrency, distribution,

inheritance, nor how the system will be built. The model of a system can be divided into multiple domains each of which are separately analysed, and represent separate business, technological, or conceptual areas of interest. The result of object-oriented analysis is a description of what is to be built, using concepts and relationships between concepts, often expressed as a conceptual model. Any other documentation that is needed to describe what is to be built, is also included in the result of the analysis. That can include a detailed user interface mock-up document. The implementation constraints are decided during the object-oriented design (OOD) process.

Object Oriented Design


Object-Oriented Design (OOD) is an activity where the designers are looking for logical solutions to solve a problem, using objects. Object-oriented design takes the conceptual model that is the result of object-oriented analysis, and adds implementation constraints imposed by the environment, the programming language and the chosen tools, as well as architectural assumptions chosen as basis of design. The concepts in the conceptual model are mapped to concrete classes, to abstract interfaces in APIs and to roles that the objects take in

various situations. The interfaces and their implementations for stable concepts can be made available as reusable services. Concepts identified as unstable in object-oriented analysis will form basis for policy classes that make decisions, implement environment-specific or situation specific logic or algorithms. The result of the object-oriented design is a detail description how the system can be built, using objects.

Object-oriented

software

engineering

(OOSE)

is

an

object

modeling language and methodology OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-oriented design methodology to employ use cases to drive software design. It also uses other design products similar to those used by OMT. The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success in the marketplace, other tool vendors also supported OOSE. After Rational bought Objectory AB, the OOSE notation, methodology, and tools became superseded.

As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE have been incorporated into UML. The methodology part of OOSE has since evolved into the Rational Unified Process (RUP). The OOSE tools have been replaced by tools supporting UML and RUP.

OOSE has been largely replaced by the UML notation and by the RUP methodology.

S-ar putea să vă placă și